From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14933 invoked by alias); 5 Dec 2014 20:39:54 -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: 33873 Received: (qmail 26933 invoked from network); 5 Dec 2014 20:39:51 -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-Originating-IP: [86.6.25.230] X-Spam: 0 X-Authority: v=2.1 cv=RcseCjdv c=1 sm=1 tr=0 a=c0CwWhpM9oUd/BnC3z6Gzg==:117 a=c0CwWhpM9oUd/BnC3z6Gzg==:17 a=NLZqzBF-AAAA:8 a=kj9zAlcOel0A:10 a=hD80L64hAAAA:8 a=Xn8LaGjDtLlXdFSiyZMA:9 a=CjuIK1q_8ugA:10 Date: Fri, 5 Dec 2014 20:34:17 +0000 From: Peter Stephenson To: "Zsh Hackers' List" Subject: Re: Interrupting globs (Re: Something rotten in tar completion) Message-ID: <20141205203417.2bc66b7b@pws-pc.ntlworld.com> In-Reply-To: <20141205181330.2b458b46@pwslap01u.europe.root.pri> 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> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 05 Dec 2014 18:13:30 +0000 Peter Stephenson wrote: > > } It's using an eval-style trap, so the "return" in it is forcing the > > } current function in the completion code to return with that status and > > } no error flagged. > > > > That was actually intentional based on the behavior complaint that led > > to the trap being added. Changing the type of trap addresses a slightly > > different problem. What we need is some way to get both. > > Well, if it aborts completely, which is certainly what I want, it will > of course return from the current function, so I've forgotten why you'd > ever want to do anything else. The trap goes back to zsh-workers/32322 (it got modified later but that was largely cosmetic). The rationale there, it appears, was it was making difficulties in interrupting easier to test (by displaying the message, I presume) --- not that it was fixing anything. So as far as I can see the underlying complaint was the same as mine, to return the shell to the point where I get control of the command line as soon as possible. Am I missing something? Do we actually need a trap at all to achieve this fundamental goal? Because the message might be helpful I don't propose removing it as long as we can (as I think we can) work around the remaining interrupt issues other ways. I'm just trying to understand if it has some other purpose. 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. pws