Packages: [Bash] Wrong highlighting for inline comment in backticks

[jfcherng]

sed -i'' \
    `# comment 1` \
    -e 's/search 1/replace 1/g' \
    `: # comment 2` \
    -e 's/search 2/replace 2/g' \
    "input.txt"

Both `# comment 1` \ and `: # comment 2` \ are wrong.

Expected (Photoshop-ed):

Actual:

• Sublime Version: 4077
• OS Version: Win7 x64

[deathaxe]

This issue is highly related with https://github.com/sublimehq/Packages/issues/1781

I still see this issue on my https://github.com/deathaxe/sublime-packages/tree/pr/shellscript/patchset-2020 branch which includes a fix for #1781.

With regards to how comments are implemented I tend to think it to be a syntax engine bug.

https://github.com/sublimehq/Packages/blob/03babb588a03ce5a1d9fd3592ce7bc265ee90d49/ShellScript/Bash.sublime-syntax#L68-L76

As the content within the backticks is embeded, I'd expect ^\s* to match directly after the opening backtick, because from the perspective of the embedded syntax the first line starts right after it.

The following lines are from patchset-2020

https://github.com/deathaxe/sublime-packages/blob/3ba826d0316f638e098412ecde443f5be90f1fcf/ShellScript/Bash.sublime-syntax#L1053-L1062

[wbond]

As the content within the backticks is embeded, I'd expect ^\s* to match directly after the opening backtick, because from the perspective of the embedded syntax the first line starts right after it.

Interesting observation. Currently I don't think we set the flags for this to be true, but I'd have to look into it.

[jfcherng]

Note that the highlighting for `: # comment 2` \ is wrong as well.

[deathaxe]

Currently, yes. But without the other issue this one would just be a duplicate.

[jfcherng]

So I guess I can close this, right?

[deathaxe]

Maybe should keep it open for a while due to the linestart matching in embedded syntaxes issue or raise it at the coreissue site.

[deathaxe]

I was able to remove the (?:^\s*|\s+) from comments match. So this issue should be resolved with the pending PR with or without core changes with regards to handling ^ at the beginning of embedded syntaxes.