Packages
Packages copied to clipboard
[Bash] Incorrect syntax parsing for zsh variable expansion ${^tmp//:/[}
What happened?
This snippet breaks subsequent highlighting of zsh code with Bash syntax package:
"${(@)^${(@)tmp:#^*:*}//:/[}]"

((don't even ask me what any of that means, lmao))
I was able to reduce that snippet down to this:
"${^tmp//:/[}]"
Without the leading ^ character it looks better and does not break subsequent code anymore:
"${tmp//:/[}]"
But that double-slash //:/… was meant to be a single operator which replaces all occurrences (I guess?) and not just the first one. Sublime Text clearly highlights it in different colors as it those slashes were not one token:

For the reference, I found this black belt magic in the _arguments completion function here: https://github.com/zsh-users/zsh/blob/b1533066ca7d50c88b37ce72093c12cf19807818/Completion/Base/Utility/_arguments#L310
This part of documentation seems relevant:
https://zsh.sourceforge.io/Doc/Release/Expansion.html#Parameter-Expansion
${name/pattern/repl}
${name//pattern/repl}
${name:/pattern/repl}
Replace the longest possible match of pattern in the expansion of parameter name by string repl. The first form replaces just the first occurrence, the second form all occurrences, and the third form replaces only if pattern matches the entire string. Both pattern and repl are subject to double-quoted substitution, so that expressions like
${name/$opat/$npat}will work, but obey the usual rule that pattern characters in$opatare not treated specially unless either the optionGLOB_SUBSTis set, or$opatis instead substituted as${~opat}.
bash is not fully forward compatible with zsh.
Fully supporting ZSH requires a dedicated ZSH.sublime-syntax be added.
There are even maybe more shell dialects needing special treatment (see: #2638).
That's true. It's a difficult situation, because hardly anyone would want to maintain two copies of shell™ syntax. I wonder, would it be so bad to just add some extra non-bash expansions to the existing syntax?
Bash already does so every here and than. They shouldn't have negative effects on Bash syntax itself though, which is not always possible. Hence #1358 is still open.
It turned out not to be a ZSH related issue, but more a general problem of priorizing braces in expansions. It effects Bash as well.