zsh-syntax-highlighting path magic blocks shell and spins up sleeping drives aggressively

[DanielSmedegaardBuus]

I like this plugin for what it provides, but please consider some way for it to coexist with this:

https://unix.stackexchange.com/questions/714952/how-to-prevent-zsh-path-completion-magic-until-i-press-tab

[danielshahaf]

Please give a self-contained description of the problem, or of the desired additional behaviour. Are you just asking for a way to disable the "this word is a filename or a filename's prefix" detection?

[DanielSmedegaardBuus]

I'm sorry for the brevity 😄 Perhaps it's not possible considering what the plugin is trying to achieve.

My initial wish — hence the stackexchange post — was for any magic to wait until I request it with TAB.

I do see now that most parts of syntax highlighting won't work with that. But, seeing as how the disk lookups are the most detrimental actions taken by the plugin (at least to someone with a setup like mine), this is just off the top of my head:

• AFAICT, paths aren't color coded, so any disk access performed is simply to check if a path points to an executable, so as to color code it.
• Script syntax color coding appear to be based on a dictionary/state machine thingie.
• Executables that aren't an absolute path are color coded based on a look-up in some cached PATH database. I assume this because if I write a new script that's in PATH and chmod'x it, it won't be color coded until I start a new session. Or maybe I'm conflating this with autocompletion on TAB... Actually, I think I am. I think actually if I manually write out the name of my newly created script in full, it's still color coded, which seems to suggest this plugin searches the PATH on disk each time I keystroke in this context.

Okay, so at least for the last part, it seems this plugin could take the same approach as the autocomplete feature does to avoid searching PATH on disk when it's trying to determine if the current string can autocomplete to an executable that's in the path. Not sure if it's using its own cache or if there's one in the shell itself, but it definitely uses a cache for this.

About the first part, it seems like a minor loss to me if one could simply configure the plugin to not try to detect executables that aren't in the path. So I won't have a green /home/daniel/.scripts/godostuff, but if I'm writing it out like that, it seems I'm already aware of where and what it is I'm typing out. Also, this could still be colored as I type if zsh-syntax-highlighting only triggered here when I pressed TAB. I'd then lose highlighting when navigating the shell history, but I'd gain the advantage of not having drives spin up and the shell blocking, simply from navigating the shell history and not typing a single letter on the keyboard.

I'm not sure, maybe it's just not a viable plugin for me to use on my system. I can see how on a very fast system with just a never-sleeping SSD, you'd have zero problems while enjoying all the benefits of this plugin. It's just been the diametrically opposite experience on my system, and it's been very frustrating, hence the arguably passive-aggressive title of this ticket, which I apologize for and will change now.

Cheers 🍻

[Rouji]

It can also make zsh borderline unusable with slow/high latency network mounts

[danielshahaf]

My initial wish — hence the stackexchange post — was for any magic to wait until I request it with TAB.

I do see now that most parts of syntax highlighting won't work with that. But, seeing as how the disk lookups are the most detrimental actions taken by the plugin (at least to someone with a setup like mine), this is just off the top of my head:

Yeah, opt-in syntax highlighting would be rather unintuitive. One could make that happen, though, fairly easily:

1. Disable the mechanism that invokes _zsh_highlight by default [the details depend on the version of zsh]

2. Bind a widget to _zsh_highlighting and invoke it at desired times

• AFAICT, paths aren't color coded, so any disk access performed is simply to check if a path points to an executable, so as to color code it.

Current behaviour is to highlight anything that exists or that is a prefix of something that exists (think /sbin/shutdow [sic]) gets highlighted too. An "Is it executable?" check does happen, but only at command position. Conversely, basenames of hashed commands are recognized without disk access.

• Script syntax color coding appear to be based on a dictionary/state machine thingie.

• Executables that aren't an absolute path are color coded based on a look-up in some cached PATH database. I assume this because if I write a new script that's in PATH and chmod'x it, it won't be color coded until I start a new session. Or maybe I'm conflating this with autocompletion on TAB... Actually, I think I am. I think actually if I manually write out the name of my newly created script in full, it's still color coded, which seems to suggest this plugin searches the PATH on disk each time I keystroke in this context.

If it contains a slash, it gets stat(2)ed. If it doesn't, it gets whence'd, which on my system ends up calling access(2). Caches happen inside whence and in _zsh_highlight_main__type (the latter isn't written to in case of aliases).

Okay, so at least for the last part, it seems this plugin could take the same approach as the autocomplete feature does to avoid searching PATH on disk when it's trying to determine if the current string can autocomplete to an executable that's in the path. Not sure if it's using its own cache or if there's one in the shell itself, but it definitely uses a cache for this.

OK. What happens if you change both instances of builtin type -w to builtin : type -w?

About the first part, it seems like a minor loss to me if one could simply configure the plugin to not try to detect executables that aren't in the path. So I won't have a green /home/daniel/.scripts/godostuff, but if I'm writing it out like that, it seems I'm already aware of where and what it is I'm typing out.

Yes, but who's to say it's executable? Say someone does «python ./foo» and then deletes the first word.

Also, consistency. Every other valid command word is highlighted in green; why not this one?

Also, this could still be colored as I type if zsh-syntax-highlighting only triggered here when I pressed TAB.

Discussed hereinabove.

I'd then lose highlighting when navigating the shell history, but I'd gain the advantage of not having drives spin up and the shell blocking, simply from navigating the shell history and not typing a single letter on the keyboard.

"Disable highlighting while navigating shell history" is really its own feature request. As proof of concept, try setting ZSH_HIGHLIGHT_MAXLENGTH=1 before navigating the history and setting it back afterwards.

I'm not sure, maybe it's just not a viable plugin for me to use on my system. I can see how on a very fast system with just a never-sleeping SSD, you'd have zero problems while enjoying all the benefits of this plugin.

What has SSD to do with anything? On a rotating disk the inodes will likely be in the page cache, and even if not, stat(2) of a random path isn't going, by itself, to cause noticeable delay…

[typkrft]

I've been having this issue, for years. It's so intermittent that it was pretty difficult to pin down. I thought my tab key was broken, or something was intermittently triggering a keypress or emulating one. Just wanted to say thanks for finding this.

In regards to mounts and the speed of a computer/ssd. I'm on a specd out m1 and this still occurs, I'm not sure if the speed of the computer has much to do with it. For me, it occurs on pretty much any command that has an autosuggestion. But it does seem to happen after coming back to terminal I haven't touched in a while, but not necessarily a period of computer inactivity.