From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2679 invoked by alias); 7 Dec 2014 01:42:51 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 33896 Received: (qmail 6912 invoked from network); 7 Dec 2014 01:42:47 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IzSnQRvMXpXDpCTCBVHj6IHAcFCgYK2Bg9hROF8ktJw=; b=LnRJ9WK1EMkeJVqHbxT+qDIRJPya+dtRGVK5mhgn7dioO0LNvlAQym4jSsgnzVJhh+ 451XWiAEjvrE+NAAeUt65/j4ye4IeKezY2WHEke2gG5xv/G6fQEVGo11noTsj19pXK8q 87oMTk9wS+nqon2peuMdfT7Yi7IT2Wous9fAsditab5JuPIWpa0agAZtLkXjpu1k9Dck J73a5T/3UvxX3E8NYzCxOa7+4kMsR+PRkTrXrIhtCEwZxPctv81uVWxZLvn33gmNBe7b V70Ex2I31His0ayJN2iMWMEZqwCQcvuCPNT3FvkU4U08bwu5vdgEnWL/ojXPpEYuHsEA K3Qg== MIME-Version: 1.0 X-Received: by 10.42.129.140 with SMTP id q12mr20685820ics.68.1417916563544; Sat, 06 Dec 2014 17:42:43 -0800 (PST) In-Reply-To: <141206094849.ZM1787@torch.brasslantern.com> References: <20141202155452.647182b4@pwslap01u.europe.root.pri> <141202084858.ZM31517@torch.brasslantern.com> <20141202172654.30e7d380@pwslap01u.europe.root.pri> <141204085606.ZM9146@torch.brasslantern.com> <20141204171226.301e9d2c@pwslap01u.europe.root.pri> <141205002023.ZM19736@torch.brasslantern.com> <20141205145054.655a2f70@pwslap01u.europe.root.pri> <141205100632.ZM508@torch.brasslantern.com> <20141205181330.2b458b46@pwslap01u.europe.root.pri> <20141205203417.2bc66b7b@pws-pc.ntlworld.com> <20141205220717.2f86bdd2@pws-pc.ntlworld.com> <141206094849.ZM1787@torch.brasslantern.com> Date: Sun, 7 Dec 2014 02:42:43 +0100 Message-ID: Subject: Re: Interrupting globs (Re: Something rotten in tar completion) From: Mikael Magnusson To: Bart Schaefer Cc: "Zsh Hackers' List" Content-Type: text/plain; charset=UTF-8 On Sat, Dec 6, 2014 at 6:48 PM, Bart Schaefer 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