Dialog Syntax Highlighting Extension for Visual Studio Code

Hello everyone,

I wrote an extension for VS Code which provides some language support for Dialog.

You can find it here at the VS Code Marketplace or inside of VS Code by searching for “Dialog” or for my handle “sideburns3000” in the extension panel (or even by just opening a folder with a .dg file in VS Code and letting the program search the marketplace).

I’ll take the liberty of reproducing the Readme here, so that people can immediately see whether it’s interesting for them (see screenshots below).

Features

  • syntax highlighting

  • bracket matching & autoclosing

  • toggling comments (to comment swathes of code in/out) (Ctrl+#)

  • automatic indentation after certain keywords – (if, then, else, elseif) – and de-indentation after (endif)

  • folding option: folds sections which begin when a line starts with # and which end when a line starts with %%%

Compiling from VS Code

In the file explorer panel, right-click on the .dg file you want to compile, and select Compile to zblorb (or z8 etc.) from the context menu.

Or: select Terminal -> Run Task ... from the menu bar and choose the compilation target.

Or: press Ctrl+Shift+B (or from the menu: Terminal -> Run Build Task...) and choose which compilation target will be regarded as the default one.

Compiler warnings and errors will be shown in the “Problems” tab, and you can click on them to jump to the corresponding line.

Note: for compilation, the extension assumes that the compiler dialogc is accessible on your system via your PATH environment variable. If that is not the case (or if you want to try out a new experimental compiler version, for example), then you can provide the full path to the compiler executable in the extension settings.

Extension Settings

This extension contributes the following settings:

  • dialog.compiler: Set the compiler executable that shall be used for compiling.

  • dialog.includeWhenCompiling: List all .dg files that shall be included when compiling, separated only by commas, in the intended order (for example: stddebug.dg,stdlib.dg). (Except for the .dg file that is currently open in the editor, as that will be prepended automatically.) The default is just the Standard Library: stdlib.dg.

Screenshots

Syntax highlighting example (the colour theme is Material Theme High Contrast):

Code folding (the colour theme is Ayu Mirage Bordered):

Compilation from context menu (the colour theme is Material Theme High Contrast):

Compiler warning, jump to the line from the “Problems” tab (the colour theme is Material Theme High Contrast):

NOT implemented

The extension does not implement intelligent autocomplete, tooltips/hover information, interaction with the debugger and other advanced features.

Release Notes

1.0.0 - 2019-09-13

Initial release.

8 Likes

Nice! I’ve been working on a Dialog language extension for VS Code myself but it’s been kind of slow going since I don’t have experience with VS Code extension creation or publishing.

I tried out yours and it is working well, though I do have a suggestion: find a way to tag bare text in rule bodies as strings so that autocomplete doesn’t try to complete every single word while you are trying to type a name or description. Especially for a large file, it gets out of hand and also makes autocomplete useless for the places where it actually matters (objects, values, etc). I was able to do this by tagging text that didn’t match anything else as string.quoted.other. Would also be nice to see a visual distinction between predicates and bare text.

Here’s the file I was working on. It’s got a couple of small bugs, but feel free to take anything from it that might be useful:

3 Likes

Cool, thanks a lot for your suggestions! I incorporated the final catch-all string matcher.

In my first version above, I tried to keep the regexes for my scopes more or less disjunct, in order to avoid depending on the order of inclusion too much (as that seemed complicated and easy to mess up). But the idea of including a matcher at the very end for everything except parentheses seems to work quite well! Everything that’s more specific will have been matched already by that time.
(And for nested scopes and all that, we have to do the inclusion stuff anyway.)

In the new version, I also tried to give the predicates and the actions some colours. By “actions”, I mean elements which appear as list items in brackets like the “look” here: (perform [look $Dir]). I’ve declared them to be strings, which gives them the same colour as the game prose in the editor (just for the “look”, the “$Dir” will retain its status as variable).
My rationale was twofold:

  1. I think it is usually something that a player will possibly see or type, and in so far has a similar role as the prose, and
  2. it’s difficult to find enough scopes/colours which are a) distinct from the surrounding colours (predicates, variables), and b) supported by the majority of themes. :slight_smile:

Unfortunately, every colour theme has its own ideas which scopes should receive different colours and which shouldn’t.

Here’s the result so far:

Screenshot from a game:

Screenshot from the Standard Library:

I think will post an updated version of the extension during the next days.

You also raise a good point concerning VS Code’s word suggestions. I need to look into that further.
When we declare everything that’s not otherwise scoped to be a quoted string, then the result seems to be

  • a) that we do not get any suggestions while typing plain text any more. That’s good (although we might have liked it for some long words), but unfortunately

  • b) we still get all the suggestions when we type something that opens a special context, so to speak. So when we type # oder (, we get suggestions both from the realm of keywords/predicates etc. as well as from the realm of our plain text game prose. And of course, as you say, that’s when we would want to get a more focussed selection of items.

Possibly the best solution would be to implement a CompletionItemProvider, and maybe I’ll do so - it seems more easily doable than implementing the full Language Server Protocol.

Looking good! Let me know when you post the update and I’ll check it out.

1 Like

LSP takes a little more work to get started, but I’d encourage giving it a try instead of building too much language analysis into the editor extension – the extension is specific to VSCode, but the LSP server would be accessible to authors using many other editors.

(I ignored this advice when I wrote the ZIL extension, but now I’m regretting it.)

1 Like

MS Visual Studio code is now available for the Raspberry Pi and works well with the inform6 extension.

Download here: MS VScode.

Select the .deb ARM version.

The Dialog extension is so/so. The highlighting is minimal.

Since Zilf does not work on the most recent version of RaspiOS, I was unable to verify VSCode with Zilf.