Sublime Forum

Bash syntax parsing

#1

Hi,
Firstly this isn’t the most pressing issue, so apologies in advance…

I’ve noticed when writing bash scripts, the double // sequence used in parameter expansion expressions is getting a style applied to the second ‘/‘ character which, in my color scheme, renders it orange in italics which looks weird.

From digging around in the color scheme it appears to being influenced by a “Function parameter” rule, but if I tweak this setting then the real function parameters (eg ones passed to a bash command with a double-dash prefix) now follow the new formatting which is a bit of a backwards step.
I assume that there is something in the syntax parser that isn’t parsing parameter expansion options quite right, but I’m now so far out of my depth in knowing where or what to change that I’m hoping someone can point me in the right direction

0 Likes
#2

May be rude to say this but you just need to post an reproduce-able code snippet and screenshot if possible. For syntax parsing issue, even if a short snippet and screenshot, it’s still better than a full screen description.

0 Likes
#3

OK, here you go:
bash_parse

Hopefully you’ll see that the ‘/’ and ‘//’ in comments are fine, but in the two lines that look like variables the second ‘/’ is (in my case), italic and orange.

I’m using color theme ‘Monokai’ and it appears to be this rule that’s influencing the behavior:
{
“name”: “Function argument”,
“scope”: “variable.parameter - (source.c | source.c++ | source.objc | source.objc++)”,
“foreground”: “var(orange)”,
“font_style”: “italic”
},

If I put my cursor on the ‘//’ and go to menu ‘Tools–>Developer–>Show scope name’ I get this:
source.shell.bash
meta.function.shell
meta.compound.shell
meta.string.shell
meta.interpolation.parameter.shell
meta.string.regexp.shell

I’ll try and capture the traceback too

0 Likes
#4

The first / is

source.shell.bash meta.string.shell meta.interpolation.parameter.shell keyword.operator.substitution.shell

The second / is

source.shell.bash meta.string.shell meta.interpolation.parameter.shell meta.string.regexp.shell variable.parameter.switch.shell

So the issue is whether variable.parameter.switch.shell appropriate. If yes, default color schemes are not managed by the community, only ST staff can make changes to them.

0 Likes
#5

OK, thanks. I’ll try and work out for myself, based on your replay, how you got to that interpretation.
Should I raise this as a (minor) bug do you think?

0 Likes
#6

I though you already known that as you said the following.

If I put my cursor on the ‘//’ and go to menu ‘Tools–>Developer–>Show scope name’ I get this:

Should I raise this as a (minor) bug do you think?

I don’t think so but I could be wrong. Technically I think if there should be a change, it’s color schemes. Syntax definition doesn’t care how they are colored. If the scope is correct, then it’s a color scheme issue.

0 Likes
#8

I don’t see how it can be a color scheme issue. Surely it is up to the parser/lexer to identify a language token after which the color scheme can do its thing.

In the example I’ve given it looks like the parser is returning two tokens whereas, in the parameter expansion case, the // pair should be treated as one.

I think it is the fact that two tokens are being returned is what is throwing the color scheme a curve ball.

0 Likes
#9

As I said on Bash syntax parsing, if you agree on variable.parameter.switch.shell is correct, then it’s a color scheme issue. Otherwise, you can go https://github.com/sublimehq/Packages to file an issue there and deathaxe (I don’t want to tag him here. If you want, you do it) will explain or fix it.

0 Likes
#10

I’m not really in a position to agree on anything unfortunately, I’ve come to ST pretty recently and don’t fully understand the minutiae. There are modifiers in the color scheme that I can’t find documented anywhere so I’m having to rely on inference and lucky-guessing

0 Likes
#11

If they are not on https://www.sublimetext.com/docs/scope_naming.html, then I think you can only do it case by case.

I am not doctrinal on writing a color scheme since it’s just for my use. I just modify things case by case for how I want them to be looked like.

0 Likes
#12

While it makes sense to scope 2nd / or % or # different, it is indeed somewhat inconsistent compared to other expansions such as ${parameter%pattern} vs. ${parameter%%pattern}.

Bash’s syntax specification is unfortunatelly not very specific about how to scope them.

0 Likes
#14

Is there anything that I can influence in the color scheme or is it down to the syntax parser (which I don’t fancy tweaking for fear of breaking it)?

0 Likes
#15

You can influence everything via color scheme.

{
    "variables":
    {
    },
    "globals":
    {
    },
    "rules":
    [
        {
            "scope": "variable.parameter.switch.shell",
            "font_style": "",
            "foreground": "blue",
        },
    ]
}
0 Likes