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