Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [BUG] With CORRECT_ALL, an interrupted correct puts a truncated entry in history
- X-seq: zsh-workers 52379
- From: Vincent Lefevre <vincent@xxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: [BUG] With CORRECT_ALL, an interrupted correct puts a truncated entry in history
- Date: Tue, 5 Dec 2023 13:57:32 +0100
- Archived-at: <https://zsh.org/workers/52379>
- In-reply-to: <CAH+w=7bZmryKWV6=kZhMU7=R9WPa+sFEFi1iJcybcJsnjw15_g@mail.gmail.com>
- List-id: <zsh-workers.zsh.org>
- Mail-followup-to: zsh-workers@xxxxxxx
- References: <20231205021217.GA357346@zira.vinc17.org> <CAH+w=7bZmryKWV6=kZhMU7=R9WPa+sFEFi1iJcybcJsnjw15_g@mail.gmail.com>
On 2023-12-04 20:10:10 -0800, Bart Schaefer wrote:
> What's happening here is that the corrections occur in-place as the
> parser reads words from the input line, much the same way that aliases
> are expanded.
>
> When you hit ctrl-c you cause an interrupt signal which stops the
> parser from reading any further input, but because it's interactive
> the shell itself doesn't exit, it just forces the parser to return.
> The history mechanism then records what the parser read so far.
>
> Conversely when you hit e.g. 'a' the parser is not interrupted,
> continues to the end of the line, and then returns. Again the history
> mechanism records what the parser read so far.
I thought that this would have been put in a temporary buffer,
until the (possibly corrected) command is validated.
> Changing this would potentially require changing the way the
> lexer+parser handle interrupt signals in general ... or changing both
> ^C and 'a' to skip the history, I suspect.
I think that ^C and 'a' should just skip the history. Just like when
one types ^C in zle, the command line is discarded and not put in the
history (here, the parser has not been involved).
> > BTW, the behavior in case of several spelling corrections should
> > be documented.
>
> Something like this?
I was also thinking about the SPROMPT documentation. The following
is inexact:
n (`no') (default)
Discard the correction and run the command.
y (`yes')
Make the correction and run the command.
One may think that the command will be run immediately after 'n' or 'y'
(i.e. not checking for other corrections). This should be like
Discard/Make the correction and prompt for the next correction
or run the command.
In particular, the current 'n' one is very ambiguous, because one may
want to run the command without any additional prompt for corrections.
So perhaps there should be a real
r (`run`)
Discard the correction and run the command (without prompting
for other corrections).
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Messages sorted by:
Reverse Date,
Date,
Thread,
Author