Re: Interrupting globs (Re: Something rotten in tar completion)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

I was extremely busy yesterday and couldn't reply to this stuff in the
order it was occurring, so apologies while I catch up back-to-front,
so to speak.

On Dec 6, 12:49pm, Mikael Magnusson wrote:
} Subject: Re: Interrupting globs (Re: Something rotten in tar completion)
}
} >>> I suspect we'll just have to try this out and see how it works.
} >>
} >> This seems to work well for me in the cases you talked about, but I
} >> quickly noticed one surprising problem. I have some stuff in my
} >> chpwd() hook to show git branches and stuff, and these used to be
} >> interruptible by ctrl-c (the commands are very fast with hot cache,
} >> but can be somewhat painful with cold cache, like 5-10 seconds delay).
} >> With the patch, I cannot interrupt them (sometimes?).
} >>
} > Ah, I think I understand what's happening now. Prior to the patch,
} > pressing ctrl-c would abort out of chpwd() completely, but now it just
} > aborts whichever single command is running. Since I have three git
} > commands in there, I now need to press ctrl-c three times to get back
} > to the prompt quickly. (I would like it to only require one).

This is almost certainly a thinko (or a missed comparison of the value of
errflag) somewhere in the errflag patch, as it implies that errflag is
NOT remaining set, and I can't come up with why using a different value
for interrupts would cause that.

} Another difference: the menu completion listing could previously be
} aborted with ctrl-c and keep the command line. It now closes the
} listing and aborts the command line. Additionally, with menu
} selection, you could previously ctrl-c out of selection and get to the
} menu, ctrl-c that again, and still have the command line. Now you just
} go straight from selection to a new empty command line.

Does this happen ...

(a) with the "trap ... INT" -> "TRAPINT()" change in _main_complete?  Or

(b) with PWS's change to errflag?  Or

(c) only with both?

I suspect this is related to why I originally used the "trap" form -- I
will have to refresh my memory, but I think having the trap run in the
context of the caller was important in some way.  (Reset in subshells
may also be a factor.)