Bart Schaefer wrote on Sat, Nov 19, 2016 at 10:00:23 -0800: > On Nov 19, 7:55am, Daniel Shahaf wrote: > } Subject: Re: Bug#844710: Fwd: Re: [Pkg-zsh-devel] Bug#844710: autocorrecti > } > } Martin Steigerwald wrote on Fri, Nov 18, 2016 at 14:15:51 +0100: > } > So two fixes to consider: > } > > } > 1) Don't confirm on space, as thats to easy to trigger accidentally. :) > } > } The code confirms on both tabs (since commit 7f1ce570) and spaces (since > } before CVS). Does anyone know a reason for doing this? > > If you have a look at the zsh-workers article referenced by 7f1ce570, > you'll see that both space and tab date from time immemorial; the patch > in 7f1ce570 actually REMOVES the interpretation of tab as "yes" from > the NO_RM_STAR_SILENT option, it didn't change CORRECT handling. >
I had looked at it, but missummarized it. Mea culpa. > Why it's this way probably has more to do with Paul Falstad's typing > habits than anything else. If you're used to hitting space or tab at > a completion, and most of the time you believe the correction, then > you probably want space and tab to mean "go ahead" anytime the shell > is waiting for something. > > Notice the RM_STAR_WAIT option for a similar situation. > > While I don't use CORRECT and therefore personally don't much care > what this prompt does, I question whether one person remarking about > this after 25+ years of it being the way it has been, is a sufficient > reason for us to immediately change it. I didn't write the patch because a guy on the internet suggested it. I wrote the patch because the semantics of tab and space at that point are undocumented and I had been convinced by the argument that using space to accept a correction violates the principle of least surprise. If we do keep space and tab then we should document them. Daniel
