Feature Request: Syntax Highlight 'script:' and 'shell:' blocks as scripts

[MillironX]

It would be extremely helpful to have script and shell blocks syntax highlighted in the proper language rather than as string literals.

Expected Behavior

Multi-line strings at the end of a process, those within an if block, and those marked as script: or shell: should have syntax highlighting matching their language. Without any label, these should be highlighted as a shell script, but a shebang would change the highlighting of that block to match the indicated language (e.g. a block starting with #!/usr/bin/env perl would receive Perl syntax highlighting). In the case of a shell block, the ! variable placeholder should receive variable highlighting distinct from the target language.

Current Behavior

End-process strings, script blocks and shell blocks are all highlighted as string literals. The only highlighting that takes place within these blocks occurs when using curly bracket variable syntax (i.e. ${var}). No distinction is made at all for the ! variable placeholder regardless of curly brackets.

Possible Implementation

A short-term fix would be to replace multi-line strings with shellscript as an embedded language. This would impede the use of multi-line strings elsewhere, but IMHO this tradeoff is worth it. This wouldn't allow for changing the language based on shebang, though.

In the longer-term, semantic highlighting might be able to highlight blocks according to shebang, and parse which are simple multi-line strings and which are code.

I don't know how/if DSL2 affects this behavior.

[ewels]

Came here to make the same issue after seeing this twitter post (and this thread below it).

Hey Phil!
Not sure if what I did will apply to you, but I followed the steps outlined in the section “Injection grammars” in this guide.

I created the TCSS grammar that you can see here: https://github.com/Textualize/tcss-vscode-extension/tree/main/syntaxes
And then I created the python.injection.json grammar that hooks the TCSS grammar into Python.

I've wanted this feature for years but never realised that it was a possibility until now.

[rodrigogiraoserrao]

I'm the OP of the linked Twitter post. Just wanted to say I'm available to give some pointers, if needed, but I'm not an expert on these matters. I essentially just followed the instructions in the extension guide that was also linked above :)

[edmundmiller]

edmundmiller/nextflow-mode#15 (comment)

Might work with https://marketplace.visualstudio.com/items?itemName=ms-vscode.anycode 🤔

[edmundmiller]

Also would give Nextflow support for Zed @mashehu

[matthuska]

I gave this a try a few months ago using tree sitter in neovim (so a little outside the scope of this repo), and it worked perfectly. It was just hacked together, but I think that route would be a good one if support beyond VScode is of interest.

Before:

After:

[bentsherman]

That would still be useful for a nextflow neovim plugin. Not sure how those work. We have a vim plugin but I'm guessing the neovim plugin needs to be separate because of vimscript vs Lua.

How did you detect and handle the string interpolation? It looks like the interpolated variables i.e. $sc2rf_dir are just not highlighted, which seems reasonable

[edmundmiller]

For reference VS Code is exploring using tree-sitter microsoft/vscode#210475

[bentsherman]

The thing is that if the language server supports semantic highlighting then tree-sitter isn't needed. But we'll have to see about the performance impact of semantic highlighting. If it's expensive then users might want to disable it, in which case they might prefer to fall back to tree-sitter instead of the TextMate grammar, since I'm guessing tree-sitter will be more accurate.

I'd also like to see the complexity of the tree-sitter grammar vs the TextMate grammar.