Sublime Forum

Color bug in Shell

#1

you need to replace the settings for shell bash.
currently shows incorrect colors.
My ver 3.2.2 build 3211 x64

need in the file :
ShellScript.sublime-package / Bash.sublime-syntax
to replace it:

       comment:
            - match: (?:^\s*|\s+)(\#)
               - match: \n

on this:

  comment:
    - match: (?:^\s*|\s+)(\#)
        - match: $

and to replace it:

- match: \blet\b
  scope: support.function.let.bash
  push:
    - meta_scope: meta.function-call.shell
    - match: $

on this:

- match: \blet\b
  scope: support.function.let.bash
  push:
    - meta_scope: meta.function-call.shell
    - match: $|\;

there may still be problems, I need to check other lines, but I only found 2 problem lines
here is an example before and after the fix:
badcolor2

0 Likes
#2

The second fix is good. The first one I haven’t looked at too closely, but I think the right place to look at fixes might be the handling of “>” instead, and what is able to pop it. This is a smaller equivalent test case:

echo "foo" > bar # comment
echo "baz"
0 Likes
#3

Thanks for the hints. The fixes need some tweaks for the following reasons, but are in general ok.

  1. Comment scopes should always include the \n to prevent completions to trigger when typing at the end of a line. Need another fix though.
  2. Fix 2 causes the ; not to be applied any scope to. Needs to be a lookahead.
1 Like
#4

Yes, you may be right. I don’t have enough knowledge to fix the error with the " > " symbol , I can only fix the problem for comments. Here we need the help of a more experienced person.

0 Likes
#5

FWIW, not from 4073 onwards (or similar).

0 Likes
#6

but if people color their comments with a background color, they may expect consistency that it will always color the \n, regardless of syntax or whether it’s necessary to scope it for AC selector purposes…

4 Likes
#7

If you know better than I do, then I ask you to pass the information on to the developers and fix bugs in future releases

0 Likes
#8

A PR to fix issue 2 (the ; thing) is pending.

It turned out fixing the comment issue without dropping \n seems not possible without heavy rewrites. Basically any builtin function suffers from this bug. Due to comments being injected into contexts via prototype they cause them to not be popped off correctly at the end of a line. From that point of view, your current solution was the best hit least effort. :wink:

0 Likes
#9

Sorry for ignorant question: Can you - meta_include_prototype: false and then pop on (?=#)?

0 Likes
#10

Might be one option, yes. Would need to place all the line-continuation and escape contexts into such contexts, too, then.

As there are a couple of contexts which need to be popped before comments as most of them are just one-liners, I am trying to go the other way around. Adding (?=#) to the pop-at-end context and remove comments from prototype placing it into main and some other multiline contexts.

2 Likes
#11

see: https://github.com/sublimehq/Packages/issues/2391

0 Likes