The point about differentiating rhs and lhs of test construct is reasonable and to me seems like it could be the original reason there are regions like shTestDoubleQuote or shTestSingleQuote (when there exist shDoubleQuote/shSingleQuote), but they are not in fact used for test command, but rather for if blocks and some other constructs. Unraveling sh.vim to get an exhaustive list is time consuming (especially since I am not well versed in vim script), but I found this rhs/lhs differentiation applies to bodies of while and for blocks as well.
Just try this: test "a" = "b" if [ "a" = "b" ]; then test "a" = "b" fi if [[ "a" = "b" ]]; then test "a" = "b" fi while :; do test "a" = "b" done for zcxv in $1; do test "a" = "b" done The first test will be different from all the other ones. At least that's how it works for me суббота, 30 мая 2026 г. в 17:27:37 UTC+3, Janis Papanagnou: > A possible explanation... > I can just point to the fact that the POSIX standard-conforming test > commands, > 'test' and '[', can be considered obsolete by ksh, bash, zsh shells at > least; because > their '[[' test construct expose less issues and they accepts on the > right-hand-side > not only a string but a shell-pattern. Thus the RHS *might* be handled > differently > because of that (in case that difference strangely made its way back to > the syntax > of the POSIX-standard and historic test commands). > > What I think would be sensible... > From a syntax highlighting aspect a differentiation of old and new test > syntaxes > would IMO make sense because the older variants (as opposed to the newer > '[[') > are symmetric in their string arguments. It should be consistent > [ string = string ] # with the same string colors > [[ string = pattern ]] # with string and pattern colors respectively > (I'm unsure whether patterns have an own special color in sh.vim , though). > > And the coloring of the test commands are of course also independent of > the 'if' > construct or presence of that keyword; they can stand for themselves. Just > BTW, > since you mentioned the context of 'if'. > > Janis > > ________________________________________ > Von: [email protected] <[email protected]> im Auftrag von > Kirill Dergachev <[email protected]> > Gesendet: Samstag, 30. Mai 2026 13:41 > An: vim_dev > Betreff: Re: Issue: test + quotes in sh.vim > > Did not get an answer and think the message is too far down in the mailing > list, so replying to get it up. > > In case the original mail was too convoluted, I could rephrase the main > question into "Is different coloring of quote characters on the lhs and rhs > of an equal sign inside of an if block intentional?" (see picture I > attached before for example) > > четверг, 28 мая 2026 г. в 07:15:44 UTC+3, Kirill Dergachev: > Hello, > > My initial issue was weird highlighting of double quotes inside of if > blocks (probably applies to for, do, etc). > For example in > > if [ "$1" = "$2" ]; then > test "$1" = "$2" > "$1" = "$2" > fi > > each occurrence of "$1" = "$2" colors whole rhs of equal sign as string > (including quotes). Then while looking for why it does that and how I could > fix it came across shTestDoubleQuote and shTestSingleQuote. Pretty sure > they are the reason this happens. (despite the name they do not apply to > test command outside of an if block) > > Is that intentional or not? > If it is not, adding matchgroup=shQuote to shTestDoubleQuote fixes the > exact problem I stated, but it is a bit more complicated for single quotes: > I guess they'll have to be changed from a match to a region like double > quotes. > > Also I don't really understand what is the reason behind separating > sh___Quote and shTest___Quote groups, can't non-test ones be used instead? > > Another small note: shTestSingleQuote also contains a '\\.' group. What > bash syntax does that cover? > > Visual demonstration of issues above: > > [Screenshot from 2026-05-28 00-10-07.png] > > (vim version 9.1, mentioned syntax groups are same on my machine and in > the newest commit on master) > > Thanks, > Kirill > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]<mailto: > [email protected]>. > To view this discussion visit > https://groups.google.com/d/msgid/vim_dev/04193508-cff4-47a3-bb9d-7a2bfe6fcaf8n%40googlegroups.com > < > https://groups.google.com/d/msgid/vim_dev/04193508-cff4-47a3-bb9d-7a2bfe6fcaf8n%40googlegroups.com?utm_medium=email&utm_source=footer > >. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/vim_dev/6cda7b9a-f9de-4c68-94cb-079ebaa1d143n%40googlegroups.com.
