-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Syntax Highlight 'script:' and 'shell:' blocks as scripts #7
Comments
Came here to make the same issue after seeing this twitter post (and this thread below it).
I've wanted this feature for years but never realised that it was a possibility until now. |
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 :) |
It would be extremely helpful to have
script
andshell
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 anif
block, and those marked asscript:
orshell:
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 ashell
block, the!
variable placeholder should receive variable highlighting distinct from the target language.Current Behavior
End-process strings,
script
blocks andshell
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.
The text was updated successfully, but these errors were encountered: