Sorry, I don't get what you're aiming at. To me the issue is quite obvious...
'test a = b' and '[ a = b ]' are both (equivalent) shell commands that should be sensibly highlighted independent of their embedding context. In their old form as '[ a = b ]' both, 'a' and 'b', are just "strings" and should thus both be handled as such. Where in the new forms '[[ str = pat ]]' and '[[ str == pat ]]' we have different types of components that may deserve differentiation. 'while test a = b' is just a part of a compound command, generally expressed as 'while any_cmd' . And with 'if any_cmd' it's accordingly. So in 'while <cmds> ; do <cmds> ; done' the control constructs will have their own highlighting and the embedded <cmds> will also have their own highlighting according the rules; for the 'test' command as described above. I don't know about the current Vim-behavior (below I spoke about a "possible explanation"); and my explanation was certainly no (positive) valuation. Rather (to me) the asymmetric coloring of the 'test' arguments is clearly a bug! And there's yet more to that; if you try... a="b" a='b' a=b In the last case the b is not highlighted as in the former two cases, but all three versions are equivalent WRT b . (The quotes are just for grouping, necessary only if, for example, the string contains white-space characters - or, more generally, if it contains characters defined in the IFS variable.) Regards, Janis ________________________________________ Von: [email protected] <[email protected]> im Auftrag von Kirill Dergachev <[email protected]> Gesendet: Samstag, 30. Mai 2026 18:32 An: vim_dev Betreff: Re: Issue: test + quotes in sh.vim 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 [https://sun9-7.userapi.com/s/v1/ig2/451ZhhawA3w2yrEKNNbw_o8GECJ8pEeahzVF5J4N6PX9wUvuC-kN89PeTXLb5uMdtlJZOVe0eUWjtSXvDR1Xr21E.jpg?quality=95&as=32x32,48x48,72x71,108x107,160x159,240x238,360x357,438x434&from=bu&u=z9i7GQh7dFXmtVHfpbz9PLVWRHgo7It7R-UNuRl-eqA&cs=438x0] суббота, 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]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/d/msgid/vim_dev/6cda7b9a-f9de-4c68-94cb-079ebaa1d143n%40googlegroups.com<https://groups.google.com/d/msgid/vim_dev/6cda7b9a-f9de-4c68-94cb-079ebaa1d143n%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/DU0PR02MB10422D70400E4A1317F73284FF3142%40DU0PR02MB10422.eurprd02.prod.outlook.com.
