Skip to content

$_ incorrectly highlighted red #619

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mxmilkiib opened this issue Jun 24, 2019 · 13 comments
Open

$_ incorrectly highlighted red #619

mxmilkiib opened this issue Jun 24, 2019 · 13 comments

Comments

@mxmilkiib
Copy link

$_ (dollar underscore) is the last parameter from the previous line. I often (with autocd on) enter "$_" directly after a command to jump into the destination directory. However it's always highlighted red. Apologies if this is covered by another issue, I went through a number but couldn't find anything directly related. Thanks.

@danielshahaf
Copy link
Member

Are literal directory names highlighted in green at command position when AUTO_CD is set? AFAICS they aren't [can't test this myself right now], so you're essentially asking for AUTO_CD support to be added. (Once literal directory names are handled, simple parameter expansions will DTRT too.)

Would you be interested in contributing this feature?

@danielshahaf
Copy link
Member

By the way, M-. (Alt+.) is equivalent and has fewer keystrokes.

@mxmilkiib
Copy link
Author

Whoops, AUTO_CD paths are made purple (on my system) not green.

I'm afraid I don't have the understanding, time or energy to implement this.

Alt-. doesn't work for me, I guess either conflict with another zsh script or bad key binds. Thank you for the tip though.

@phy1729
Copy link
Member

phy1729 commented Jun 24, 2019

It's a bit more complicated than just supporting AUTO_CD. Currently _ is not recognized as a parameter name

readonly parameter_name_pattern='([A-Za-z_][A-Za-z0-9_]*|[0-9]+)'
. The hard part is expanding _ properly. We'd need to save the value of _ and then special case the expansion code because _ will have changed many times over once we've gotten to here

@danielshahaf
Copy link
Member

danielshahaf commented Jun 25, 2019

That pattern would match $_ 's name, but if we are able unable to compute the correct expansion, we might have another use-case for the envisioned indeterminate style — not just for $_ but for any [[ ${(t)foo} == *special* ]] parameter at command position, unless whitelisted as an exception?

@danielshahaf
Copy link
Member

See #617 for indeterminate (although that term isn't used there).

@danielshahaf
Copy link
Member

danielshahaf commented Jun 25, 2019

My reading is two separate issues:

  • Support AUTO_CD.
  • Don't expand special parameters at command position.

@phy1729
Copy link
Member

phy1729 commented Jun 25, 2019

Indeed it does match $_ oops. I agree in general special parameters should use a indererminate style; however, I think $_ is useful enough to special case. There may be a cleaner way, but worst case we could save ${${(z)BUFFER}[-1]} on zle-line-finish.

@danielshahaf
Copy link
Member

danielshahaf commented Jun 25, 2019 via email

@phy1729
Copy link
Member

phy1729 commented Jun 25, 2019

Nothing. However, highlighting on the modified line would already be incorrect for those users (and we do document that we should be sourced last).

@danielshahaf
Copy link
Member

danielshahaf commented Jun 26, 2019

Fair enough. Re 'cleaner way', I thought we could have zle expose the REPL-level value of $_ through a new preset variable (akin to BUFFER, WIDGET, &c). WDYT?

@danielshahaf
Copy link
Member

For the record, AUTO_CD support is in #669 (PR for 0.8.0) and parameters in command position are #674 (has WIP PR). Support for $_ specifically would require further work, as discussed in this issue.

@danielshahaf
Copy link
Member

Cross-referencing #695.

danielshahaf added a commit to danielshahaf/zsh-syntax-highlighting that referenced this issue Mar 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants