From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3788 invoked by alias); 6 Dec 2014 11:49:38 -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: 33884 Received: (qmail 24016 invoked from network); 6 Dec 2014 11:49:25 -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=1SFO/MVDO0IQXltGKD9xpcmIvhMN2Ef0Fn6tdBI5Wzw=; b=K1RfVXciBbJG4vqRKSDTW9sPKkfFMlDY12yOGKpE3wOP6TA1r01yHwbA5I2Mo+YgTh gmrfD3v6HjBF7Arv5Ckj7maekJX4fMozEmo07wrhv2Fj3o/SZmjP1P59eGtD+pTTSVQ2 Teb5MWdZFICSKAza2VB882ZcLdkzxuo3SvPmRQOyP1DC6qvkGS0Yzc9QQERny8XLsc/7 9RQVv5M0ABJU4hb5Hvn401hAdfktpD3l7xccliMR23iNq10q8SXomWwoZxBpAdCCpJNn WysNybQWT7IKEyxMvirlJKXtR1JQ2hvB9lbkE3eZXWXI9TtWrR8JQITpd0zY6aroPym2 Db0A== MIME-Version: 1.0 X-Received: by 10.43.158.197 with SMTP id lv5mr19512969icc.88.1417866559945; Sat, 06 Dec 2014 03:49:19 -0800 (PST) In-Reply-To: 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> Date: Sat, 6 Dec 2014 12:49:19 +0100 Message-ID: Subject: Re: Interrupting globs (Re: Something rotten in tar completion) From: Mikael Magnusson To: Peter Stephenson Cc: "Zsh Hackers' List" Content-Type: text/plain; charset=UTF-8 On Sat, Dec 6, 2014 at 1:52 AM, Mikael Magnusson wrote: > On Sat, Dec 6, 2014 at 1:36 AM, Mikael Magnusson wrote: >> On Fri, Dec 5, 2014 at 11:07 PM, Peter Stephenson >> wrote: >>> On Fri, 5 Dec 2014 20:34:17 +0000 >>> Peter Stephenson wrote: >>>> 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. >>> >>> Here's my first go; it does seem to do what I want, and as a by-product >>> fixes all the little race conditions we've always had that meant you >>> couldn't interrupt chunks of code that were executed in any kind of >>> sandbox because the condition got reset afterwards. I think a few of >>> these have been annoying me over the years. >>> >>> 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. >>> >>> Correspondingly, most of the time only the ERRFLAG_ERROR bit gets >>> reset. ERRFLAG_INT gets reset only in the following cases: >>> >>> - in the main command loop. This is what causes the shell not to exit but >>> instead go back to the main command loop when you ^C a command. >>> >>> - 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 since >>> in this case you'd typically expect the previous condition to have >>> occurred and it could mean e.g. you ignore an interrupt that >>> occurred just before a "vared". >>> >>> - 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. >>> >>> 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. >>> >>> By the way, looking at the patch below you might wonder if it wouldn't >>> be more efficient to add a separate flag for interrupt error conditions >>> to test. It wouldn't --- there are many more cases where errflag is >>> tested than when it is set, not affected by the patch below. >>> >>> 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). 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. -- Mikael Magnusson