SH_WORD_SPLIT variable expansions in command positions are incorrectly highlighted

[kbd]

As reported in a different thread, aliases to environment variables are highlighted incorrectly:

Using Homebrew installed version 0.7.1.

[danielshahaf]

With the first definition in effect, what happens when you run the e alias?

Is the SH_WORD_SPLIT option set?

[kbd]

Good questions. sh_word_split is set, and I have my $EDITOR set to open -t on Mac so it opens the default system text editor (vscode):

When I run the first e, it runs open -t and correctly opens vscode. When I run the second e it opens vim.

Edit: this alias is one of the reasons I have sh_word_split set. For reference, here's what happens when it's not set:

The first e runs correctly while the second one fails.

[danielshahaf]

Retitled the issue; it's not specific to aliases, nor to environment variables.

Edit: this alias is one of the reasons I have sh_word_split set. For reference, here's what happens when it's not set:

You could leave shwordsplit at its default value (unset) and change the alias: replacing the alias by a function definition such as e() { eval $EDITOR "${(q)@}" } should DTRT.

If you want to look into adding shwordsplit support, that would probably require having the parameter expansion code consult ${zsyh_user_options[shwordsplit]}.

[danielshahaf]

Test added in 34df84a.

[danielshahaf]

e() { eval ${(q)=EDITOR} "${(q)@}" } is more robust against metacharacters in the value of $EDITOR. (However, I'm not at my workstation, so double-check my ${(q)=foo}.)

[kbd]

Thanks for the shell tips! When I switched from bash years ago that 'open -t' alias stopped working, so I found the zsh option that made it behave more like bash there. I haven't run into any cases where that option causes unexpected behavior for me.

One more thing I should have mentioned initially but neglected to: this incorrect highlighting is new in version 0.7.0 or 0.7.1. When I updated Homebrew I was able to compare against shell sessions still open from the prior version and it didn't have this behavior.

[danielshahaf]

I haven't run into any cases where that option causes unexpected behavior for me.

Well, SH_WORD_SPLIT is off by default, so I expect sooner or later you'll run into a code sample for native zsh that assumes that option is at its default value.

One more thing I should have mentioned initially but neglected to: this incorrect highlighting is new in version 0.7.0 or 0.7.1. When I updated Homebrew I was able to compare against shell sessions still open from the prior version and it didn't have this behavior.

Thanks. I've labelled this a regression, but I don't think there's much to be gained from bisecting this, since we already have an idea of the root cause: #687 (comment).