Zsh Mailing List Archive
Messages sorted by:
Re: Interrupting globs (Re: Something rotten in tar completion)
On Fri, 05 Dec 2014 18:13:30 +0000
Peter Stephenson <p.stephenson@xxxxxxxxxxx> wrote:
> > } It's using an eval-style trap, so the "return" in it is forcing the
> > } current function in the completion code to return with that status and
> > } no error flagged.
> > That was actually intentional based on the behavior complaint that led
> > to the trap being added. Changing the type of trap addresses a slightly
> > different problem. What we need is some way to get both.
> Well, if it aborts completely, which is certainly what I want, it will
> of course return from the current function, so I've forgotten why you'd
> ever want to do anything else.
The trap goes back to zsh-workers/32322 (it got modified later but that
was largely cosmetic). The rationale there, it appears, was it was
making difficulties in interrupting easier to test (by displaying the
message, I presume) --- not that it was fixing anything. So as far as I
can see the underlying complaint was the same as mine, to return the
shell to the point where I get control of the command line as soon as
possible. Am I missing something? Do we actually need a trap at all to
achieve this fundamental goal? Because the message might be helpful I
don't propose removing it as long as we can (as I think we can) work
around the remaining interrupt issues other ways. I'm just trying to
understand if it has some other purpose.
On the other problem I came up with, that eval is resetting errflag even
if you've interrupted: how about the following? Add a bit to errflag to
signify that the user interrupted the shell rather than that some
internal error (e.g. syntax) occurred. Only reset this new bit in a few
key places: the main command loop when executing, the top of ZLE when
editing being the obvious places. Convert other "errflag = 0"
assignments case by case so that they just remove bit 0; then eval can
continue to do its job of acting as a sandbox but without screwing up
the behaviour of interrupts. I think doing that is fairly mechanical
and it achieves what's needed without compromising anything else.
Messages sorted by: