high max-errors causes prolonged max-cpu consumption

[catharsis]

So, I don't know if the solution here is "so don't do that", but I figured it might be worth bringing it up;

https://github.com/sorin-ionescu/prezto/blob/master/modules/completion/init.zsh#L70 sets max-errors to the length of PREFIX+SUFFIX/3. Now I'm completely new to this, but on my system, this means that doing something like

ls aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa<tab>

when no file with a similar name exists in the current directory causes zsh to hang and peak on CPU% for a long time. The time needed to complete seems to grow close-to-exponentially. I know this example is pretty contrived but I think it demonstrates the issue well enough.

So, my query is: is there a better, perhaps more conservative way to set max-errors to avoid this hanging? It seems to me that deciding on a ceiling for max-errors, based on some clever heuristics might be worthwhile.

[el1t]

I agree, the errors should definitely be capped. Most commands shouldn't have more than 10 errors anyways. For me, something like

zstyle -e ':completion:*:approximate:*' max-errors 'reply=($((($#PREFIX+$#SUFFIX)/3>7?7:($#PREFIX+$#SUFFIX)/3))numeric)'

capped it at 7.

[catharsis]

@el1t That works much better; I took the liberty of submitting a PR with your change.

[el1t]

@catharsis cool glad I could help!

[sorin-ionescu]

Can you show me an example of when you got high CPU usage? I'd like to test it myself.

[catharsis]

@sorin-ionescu As described in the original report; Simply doing ls aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa<tab> in a shell without the patch from #953 applied would cause zsh to consume 100% CPU on one core for an indeterminate time (I never cared to wait it out) trying to complete the completely wrong path. Shorter paths (smaller search-space) result in shorter time.

Of course, the same effect is seen for any path completions that aren't close to anything that exists in the file system.

[sorin-ionescu]

Don't type so many a then.

Give me a real usage scenario. I'm asking because I have had no trouble with the current maximum errors.

[catharsis]

Ok, I see what you're saying, my mistake.

Well, consider for example the case where you're the kind of person who copies instructions from the internet when you're trying to fix a problem. The instructions say you should edit /usr/local/etc/fooserviced/config/init.cfg, so you copy the path and press tab to make sure you copied the entire thing correctly, but "oh no!" your corresponding config file is not in /usr/local at all, and now your shell is no longer responding: sucks to be you.

Or, perhaps you have a temporary device or file system at ~/somedevice and you have a command in your history to cat a file on it (or whatever). So you recall the command by doing ^R, get cat ~/somedevice/my_cat_pictures/2001-08-12/cute_kittens.png and tab just out of habit. But, too bad, you forgot you unmounted your device, because your spouse desperately needed some cat pics right now, and now you're stuck with an unresponsive shell and no kittens.

[catharsis]

Here's another example that I just ran into:

I had a git commit that I needed to cherry-pick from a branch in my clipboard. I started typing:
git cherry<paste> My command line now looks like git cherry0e454967543e53624cceebd3fa4ab11260a9b024. I put my cursor at the end of cherry, and tab, thinking it'd result in git cherry-pick 0e454967543e53624cceebd3fa4ab11260a9b024. Instead, my shell becomes unresponsive and I have to kill it.

[catharsis]

@sorin-ionescu Do you agree that this is a valid issue? Is there anything blocking #953 from getting merged?

[sorin-ionescu]

It is a valid issue. Nothing is blocking merging it. I will merge it.