Semantic Highlighting in Inform 7

Now that we know there’s potentially interest in adding semantic code highlighting to the Inform 7 IDEs, it seems like some discussion is in order over how this would look and what exact functionality it would offer.

I started playing around with some ideas for how this might look and what exactly it would do, taking a subset (highlighting objects) of the initial idea:

http://aaronareed.net/if/semantic-test.html

Edit: Updated version here: http://aaronareed.net/if/semantic-test2.html

(This all assumes that some sort of background compiling is taking place.)

Essentially, what’s proposed here is:

– Highlight all the words understood as a new object in an assertion sentence.
– Highlight words understood as referring to a previously created object in a different, much more subtle color.
– Highlight articles in assertion sentences when they’re understood as meaningful.
– Hover-over to reveal problem messages with misunderstood sentences, and full names of referenced objects.

Any feedback is welcome-- if other people want to take the other sections and run with them, or offer counter-proposals, that would be great too. Feel free to grab the styles off my page as a start.

Also, I should add that I don’t know what’s technically possible with the current infrastructure, or what the IDE maintainers are willing to add-- this is in no way a promise of future functionality, just a discussion over what sort of more specific proposal we might want to make to the Inform team.

This looks great!

I like the idea. My concern is that I wouldn’t want it to look jumbled. Syntax coloring I like. Highlighting with a virtual Magic Marker I’m not so sure about. Maybe it would be best to have a button that would turn all this stuff on or off, so that the author could just write and not be distracted by a lot of graphic hoo-hah.

I like the idea of having the IDE perform a preliminary compilation pass (in the background, more or less continuously, like a spell-checker) to identify new objects, previously referenced objects, and so forth. I like the idea that a hovering tooltip might give you some useful information about a meaningful word (such as an object or variable name).

I’d like to see a command that would open a sort of search window that would list all of the places in the source text where a given object was mentioned. Then you could jump to any of those items by double-clicking.

Ultimately, I think syntax highlighting may not be the place where the primary development effort should go at present. I would tend to want to see a higher priority given to eradicating library bugs, improving the documentation, and creating some sort of namespaces for extensions. My personal view is that the latter efforts would pay bigger dividends for more authors. But I could be entirely wrong about that – that’s just an off-the-cuff thought.

–JA

I like the idea!

Jim, this would probably be mainly on the IDE side, whereas the problem areas you identified are parts of the core/common I7. So different people would be working on different things. Now whether the IDE maintainers have the time or inclination to do this is another question…

I’m not really identifying much of anything that would qualify as an unresolved “library bug” on Mantis at the moment (that is, something indicating flaws in the Standard Rules rather than to the compiler). If the bug database is missing information, by all means please add it.

I like the idea of what would be highlighted and how; personally, I would also prefer to have that information shown in a more subtle way, with colored text rather than highlighter markup.

Many IDEs that support this type of semantic analysis are quite configurable, allowing you to choose the foreground and background colors you want. I think if we can agree on what categories of entities are available for distinction, folks will be able to come up with color schemes that please themselves.

I like the categories proposed; I also feel it would be helpful to do inline spell-check on any non-token text inside double-quotes, but this might cross into a separate feature request.

Love this, although I would hope it would customizable/easily turn-offable. I like the spell check idea as well.

This is good for objects, but much, much less than what semantic highlighting should cover.

I want to be able to see any multiple-word phrase that the compiler decides is a thing. That includes phrases, definitions, relations, activities…

I realize there’s a best-is-enemy-of-the-good problem here (a partial solution has real value). But I don’t think it’s safe to say that the majority of compiler confusions are object-vs-object. The “active” discussion (see other thread) is an example. What kind of highlight/tooltip model would allow the user to point at “active” and discovery that this error is a conflict between his Boolean property and the library’s definition on use options?

(I just re-read and saw that you were explicitly proposing a subset of the original idea. Sorry if I got ranty about it.)

I do have some presentation ideas, but I’m at PAX without a decent HTML editor. I’ll try to post something next week.

Let me explicitly disagree with Jim, by the way. This is an important topic and worthy of core development tine.

The Uservoice users have it as their top priority by a good margin. While the popularity of a suggestion doesn’t always guarantee that it can be done, we do take that seriously.

Not to be snarky or anything … but I just went up to the I7 site, and the current version is still 6E72. I seem to recall that there was a flurry of bug reporting after that release. Was I wrong? Have no bugs been reported, other than compiler bugs?

I seem to recall that in testing last month, I learned that while game titles can now contain word-ending apostrophes, they can’t contain double-quotes. Thus, a game can’t be named this:

“Repent, Harlequin!” Cried the Tick-Tock Man

That’s a trivial example, and I didn’t bother to report it … but are you telling us that you believe the library to be entirely free of bugs?

–JA

That’s certainly not what I wrote, no.

If your irritation is because you think I shouldn’t be nitpicking your use of the term “library bug,” I did so because I was trying to discover whether you meant “I think developer time is best spent on fixing bugs, full stop” or “I think developer time is best spent on a set of missing features, syntax oddities, et alia that I personally find frustrating and contrary to common sense.” If the former, then, well, we do try to work through the bug database. If the latter, then that’s a set that is hard to identify unless you are willing to report those issues individually.

The double-quote issue you raise would be a compiler bug, unless it’s a missing feature. (The documentation looks ambiguous on this point, so I could imagine people arguing that part either way.) Feel free to report it at either Mantis or Uservoice, but it’s not something that can be fixed with a tweak to the Standard Rules.

I agree – it seems like it’d be nice to be able to type in monochrome and then turn the colors on and off again when you wanted to check something.

This would absolutely have to be an option that could be turned off, yes – not only to avoid driving people crazy with the dancing colors (though that’s a valid issue), but also because it would require background compilation that would be draining for laptops.

Personally, I don’t see the value in dynamic syntax highlighting for Inform (the feature itself I think is important—I just don’t see any compelling reason for it to be dynamic). I definitely don’t relish the thought of writing with a riot of color going on, because I feel like it will be somewhat harder to grok syntax-colored I7 than the primarily keyword- and punctuation-based highlighting of a traditional programming or markup language. In the same way I avoid the red underlines of dynamic spell-checking and instead use the manual “check spelling now” command, I would want to see syntax highlighting only when it’s likely to be useful to me.

So, toggling the feature needs to be not only possible, but effortless—say, with a button on the main toolbar rather than a checkbox buried in the preferences. That way, you can manually toggle highlighting when you have a particular question at hand.

–Erik

While I’m warm to Jim’s general interest in prioritizing other stuff, we’re clearly in a small minority.

I would like to praise an existing feature: the spellchecker in Inform’s IDE (at least on Mac). It puts a dotted green underline under a misspelled word shortly after you type it, and I have found that to be very useful. I certainly wouldn’t mind the corresponding dotted red underline under a grammar error, as many word processors work this way. (I think MS Word uses a squiggly line instead of a dotted line, but the same colors.) And unlike a word processor’s grammar complaints, this one would carry a lot of weight!

Question: should the syntax coloring color according to programming construct (object, scene, etc.) or grammar category (noun phrase, participial phrase, assertive statement)? There’s something of an unwritten rule that certain constructs “belong” in certain categories. For example.

object names, scene names, To Decide Which phrases = noun phrase

actions, activities = participial phrase

To phrases = assertive statement (usually imperative statement, except for ones like “To (P - person) ponders (O - object): …”)

To Decide Whether = as independent clause, but to be transformed into a dependent clause via prepending if, unless, when, whether or not, etc.

And so on. There are a couple of gotchas in the language if you don’t name a construct within the particular English category. (See the programmer’s manual, Grammar Gotchas, with regard to naming Activities after a noun phrase.)

I think I’ve found a bug in the Standard Library. I tried to report it at uservoice, but I’m not sure I formatted my suggestion correctly:

inform7.uservoice.com/forums/573 … s-nothing-

The bug-reporting site is inform7.com/bugs. Uservoice is for suggesting new features.

–Erik