Re: PATCH: Don't store ZLE_LINE_ABORTED in vared context

[Peter Stephenson <p.stephenson@samsung.com>]

On Wed, 4 Mar 2015 19:40:03 +0100
Mikael Magnusson <mikachu@gmail.com> wrote:
> send-break (^G ESC-^G) (unbound) (unbound)
>        Abort  the current editor function, e.g. execute-named-command, or the
>        editor itself, e.g. if you are in vared. Otherwise abort  the  parsing
>        of the current line; in this case the aborted line is available in the
>        shell variable ZLE_LINE_ABORTED.
> 
> However, pressing ctrl-c inside vared stores whatever was being edited
> in ZLE_LINE_ABORTED, which the above seems to imply should not happen.
> The following adjusts the code accordingly. It was actually a bit
> annoying if you set up a widget to do the up-line-or-aborted, because
> it will grab the vared text as a command then.

I'm not really sure I decided clearly one way or the other which was
likely to be better, so it's more a matter for experience rather than
the original intention.  I do seem to have been fairly deliberate with
the documentation, though; the "otherwise" doesn't seem to leave much
doubt.

Having the variable set in special cases is a bit of a headache, I
agree, since you don't necessarily know they're there, even if there are
ways round.

It would be tempting to have a different variable for the vared case
such as ZLE_VARED_ABORTED.

pws