From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13011 invoked by alias); 7 Dec 2014 05:18:24 -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: 33899 Received: (qmail 3209 invoked from network); 7 Dec 2014 05:18:23 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=IOK10brD c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=A92cGCtB03wA:10 a=EvEGJux7Hvl8MXuxkl4A:9 a=GDYVRmCs86jM2f1R:21 a=rN-4JW4BiqTuvBn_:21 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <141206211828.ZM15934@torch.brasslantern.com> Date: Sat, 06 Dec 2014 21:18:28 -0800 In-reply-to: <20141205220717.2f86bdd2@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: Interrupting globs (Re: Something rotten in tar completion)" (Dec 5, 10:07pm) 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> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Hackers' List" Subject: Re: Interrupting globs (Re: Something rotten in tar completion) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Whew, caught up I think ... On Dec 5, 10:07pm, Peter Stephenson wrote: } } The general strategy is to use the bit ERRFLAG_ERROR for internal } failures and ERRFLAG_INT for user interrupts. There are only two } cases of the latter: on an untrapped SIGINT, the obvious case, and also } on a trapped SIGINT or SIGQUIT where we've been told to behave as if the } trap didn't trap the error condition. That's straightforward for } SIGINT, less so for SIGQUIT but I took my cue from the fact that Bart } thought it worthwhile trapping SIGQUIT as an interactive "no, I really } mean abort" in completion, which implies that if we trap it we want it } to work at least as well as SIGINT. I would say that INT should be "less drastic" than QUIT. For example in the cases Mikael mentions in subsequent messages -- stopping menu selection, etc. -- the ideal thing would be if QUIT broke all the way out to a new command line while INT backed up only one level. However, I'm not sure how QUIT behaved before (or even whether it is enabled as a keyboard-generated signal, since we don't have a handler for it) -- I trapped both INT and QUIT there because they both *could* come from the keyboard, if stty were configured for it. } Correspondingly, most of the time only the ERRFLAG_ERROR bit gets } reset. ERRFLAG_INT gets reset [...] } } - at the start of zleread, so we can read the next thing to do whatever } just happened. I'm not sure this is particularly useful But the situation before this patch is the same, is it not? } - when we just finished completion. This is needed so that the cases } that got this whole business kicked off behave as now (but more } reliably) --- a ^C gets you back to the command line, but the command } line is not trashed as it would be if you ^Ced outside completion (try } it if you're confused). There's a race here, but it's no worse than it } ever was. I think Mikael's example shows there are sub-cases of completion where we need to add clearing of interrupts, rather than backing all the way out of completion. } To ensure ERRFLAG_INT doesn't get reset unnecessarily there are a number } of cases where restoring errflag to a previously saved value keeps the } ERRFLAG_INT bit if it got set in the meanwhile. I hope the rationale } here is obvious --- the ERRFLAG_ERROR is an internal state that needs } resetting, the ERRFLAG_INT an asynchronous condition where the user } doesn't care what the internal state is. Are there any cases where errflag is unconditionally restored, or did you change all such save/restore pairs? Either the ternary is irrelevant here, or the "if (errflag)" is: } @@ -2691,7 +2702,7 @@ execcmd(Estate state, int input, int output, int how, int last1) } if (varspc) } addvars(state, varspc, 0); } if (errflag) } - lastval = errflag; } + lastval = errflag ? 1 : 0; } else } lastval = cmdoutval; } if (isset(XTRACE)) {