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

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Sat, Dec 6, 2014 at 6:48 PM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> 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.)

It doesn't happen with only (a). It does happen with only (b). (c)
behaves the same as (b), as far as I can tell.

@@ -883,7 +883,7 @@ getbyte(long do_keytmout, int *timeout)
         die = 0;
         if (!errflag && !retflag && !breaks && !exit_pending)
             continue;
-        errflag = 0;
+        errflag &= ~ERRFLAG_ERROR;
         breaks = obreaks;
         errno = old_errno;
         return lastchar = EOF;

Undoing only this hunk fixes this for me. I can't find anything that
stops being interruptible but I only tried for a minute.


@@ -1444,12 +1444,7 @@ zwaitjob(int job, int wait_cmd)
         restore_queue_signals(q);
         return 128 + last_signal;
         }
-        /* Commenting this out makes ^C-ing a job started by a function
-           stop the whole function again.  But I guess it will stop
-           something else from working properly, we have to find out
-           what this might be.  --oberon
-
-        errflag = 0; */
+        errflag &= ~ERRFLAG_ERROR;
         if (subsh) {
         killjb(jn, SIGCONT);
         jn->stat &= ~STAT_STOPPED;

And commenting that line back out fixes my chpwd() hook ctrl-c thing.
(or changing it to errflag &= ~ERRFLAG_INT; but I have no idea if that
makes any sense).

I'll run with these two changes for a while and see if anything pops out.

-- 
Mikael Magnusson