As I’ve been teaching myself Inform 7, I’ve noticed some program-language-ish elements that aren’t part of the built-in syntax highlighting.
If I’m understanding the idea of ‘things’ and ‘kinds,’ could these things be highlighted differently? Is there anything already doing this as an extension or a different text editor?
(I did find Vimform7 which does highlight the, um, joiners? Not sure of the correct term there. Basically, ‘the’ ‘of’ and ‘the description of the’ from what I can see in the screenshot. At least with these it would make it visually easier to see the things and kinds I’m playing with.
I’m hesitant to jump into Vimform7 if only because I’m just learning Inform 7 and so to ALSO try to learn VIM might be too much alongside my other studies. Not to mention not being sure how that IDE would play with other extensions which I may or may not need for my project.
The quick answer is, you can’t. The syntax of Inform 7 is too ambiguous to know for sure what is a kind or a thing and highlight them (especially with the regex-based highlighing provided in a lot of editors). That’s at least my opinion.
I guess you could at least highlight built-in words such as thing or open. But my opinion is that there’ll be too much false positives.
I hate when words such as the or of are highlighted because it will then also highlight them when they are e.g. part of the name of an object/rule, and not when they are used as “joiners”. It becomes distracting.
(As an additional hurdle, you can technically translate Inform’s syntax so that it’s in, say, French. So your editor would need to handle that, too. Admittedly it doesn’t matter for most people.)
What would be ideal is that the compiler has a mode that parses the source without compiling and pass that information to the editor so you could have perfect highlighting. But I’m not sure it would be fast enough.
I’ve been using this inform-mode for Emacs, but the syntax highlighting isn’t that great, 'cause it’s not feasible for it to be great for the reasons @Natrium729 gave.
It occurs to me that if someone committed to some voluntary set of conventions regarding naming, for instance, that object names always began with ' and never had spaces, they could customize their syntax highlighter to respect those conventions and get improved results personally… but I don’t think any two people are likely to agree on the scheme, so it would continue to be a personal thing.
Taking a look over there, I think I might give that Emacs mode a try! It might not be perfect, but to my newbie Inform 7 eye, it’s still doing most of what I’m looking for.
I had wanted to stay in the Inform 7 IDE, but this is compelling me.
This seems more robust so far than even Vimform7, and it sounds like it can probably compile it as well? And I suppose you can go back to the I7 IDE for the Skein and Index tools and such.
I compile from the command-line and never use the IDE. It wouldn’t be hard to set up compilation via Emacs, but I’ve never gotten around to it. One could even launch the resultant game in a terp within Emacs, but emacs-glulx is sloooow. Malyon for Z-code is fine, though.
This is what’s generally known as a “language server” in editor-land. The nice part is that the compiler can pass back information about errors, available autocomplete values, and so on as well as syntax coloring.
This is valuable even when the language compiles slowly. (I’ve used this sort of editor with Unity/C#, and Unity compiles are not speedy.) You spend more time reading code than typing; if it takes a while for the syntax coloring to catch up with your fingers, that’s fine.
However, I don’t know anything about the Language Server Protocol itself. It’s meant to support any language, so it’s probably capable of handling the kind of grammar markup that I7 would require. But it would be a research project to figure out the details, and then another project to get the I7 compiler to generate that data and pass it off to a server.
An I7 extension is just another text-file, so it’s very easy. But there aren’t features to manage them in any way; you’d be one your own.
(With the coming I7 v11, a new extension format is favored in which each extension is in its own directory, with separate files for the source, the documentation, and each example. Handling that without some explicit in-editor support would start to be a drag.)
Yes, that was my idea: have a special mode in ni so that it creates diagnostics instead of a story file, and write a language server that bridge this diagnostic with editors. But the ni part and the editor part are fairly independent (the language server would read the diagnostics and convert them to messages to send to the client; just JSON, I believe).
The slowness could be problematic when asking for autocompletion suggestions and tooltips, I think. For the highlighting, it not as much a problem, that’s true.
Another solution would be to write a brand new parser using the Preform, that specialise in outputting diagnostics for a language server. But that would be even more work.
Anyway, just to say I don’t think having a real Inform highlighter won’t happen soon.
FYI, I don’t use inform anymore so I haven’t been trying to improve the emacs inform mode much, but if anyone did come up with some form of Hungarian notation or Perl style prefix notation to denote the type of names in inform code, and enough people agreed to it, I would absolutely take the time to put it into my plugin!