Closed jeff-hykin closed 7 months ago
I was thinking about making a second issue, for this. It'd be nice for HEREDOC
to be pink again.
The frequent bit of code that I use that has lost its color is this:
eval "$(
cat <<-HEREDOC |
blah blah blah
HEREDOC
git rev-parse --parseopt --stuck-long -- "$@" ||
echo exit $?
)"
@akpircher So you should already be able to color them whatever you want them to be
punctuation.definition.string.heredoc
is the TM scope, and here's a tutorial on how to color a TM scope with whatever color you want:
https://medium.com/@jeffhykin/how-to-customize-your-vs-code-text-colors-c0191155f41a
To get the colors for your current color theme, you can go Help->toggle developer tools, then use inspect element, click on the text that is that pink color, and look at the CSS properties to find the exact color.
I actually already do some customization in my user settings, I just wasn't sure if the intention of the new grammar was for HEREDOC's color was to be detected by the keyword.control
scope, or if it's supposed to be its own scope for alternative colorization. (Or whether VSCode should update it's theme for HEREDOC colorization)
I actually already do some customization in my user settings
Cool!
I don't know what the old syntax tagged them as, but keyword.control
is intended for control flow (if, then, while, case, do, etc) so yeah, heredocs won't be tagged with keyword.control
moving forwards. They're tagged similarly to quotes around a string.
keyword.control
is intended for control flow (if, then, while, case, do, etc)
@jeff-hykin what do you reference when deciding what scope name to give to a specfic token? is there a doc you use or do you just memorize a bunch of standards you have?
if you've seen my extension, you'll see I've applied scope names based (mostly) on their colour in vscode rather than their definition ;}
I've spent so much time thinking about what to name things. Usually I follow the basic naming guidelines from Textmate, when things fall outside of that I try to look at other languages with similar concepts, and then in the worst case I add a preexisting scope that is blatantly wrong, but then include another scope right after that is rarely used; meaning by default it will have some highlighting, and then have a more specific scope for someone trying to override it.
My goal that isn't ever going happen but would be to have a common set of standard scopes that are all prefixed with std.
for cross-language highlighting and then have a prefix of custom.
for any scopes that were language specific.
Alright tabs issue should be solved
More of a reminder to myself: there's potential issues with
cat <<-HEREDOC *tab* | blah blah blah