From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6266 invoked by alias); 8 Dec 2014 21:20:36 -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: 33936 Received: (qmail 27211 invoked from network); 8 Dec 2014 21:20:32 -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=RdIeCjdv c=1 sm=1 tr=0 a=c0CwWhpM9oUd/BnC3z6Gzg==:117 a=c0CwWhpM9oUd/BnC3z6Gzg==:17 a=NLZqzBF-AAAA:8 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=bIRuJXQGHr3WaxDHYBMA:9 a=CjuIK1q_8ugA:10 Date: Mon, 8 Dec 2014 20:27:17 +0000 From: Peter Stephenson To: "Zsh Hackers' List" Subject: Re: Interrupts in completion, traps in _main_complete Message-ID: <20141208202717.46678b7d@pws-pc.ntlworld.com> In-Reply-To: <141207150140.ZM24076@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> <141206215911.ZM16010@torch.brasslantern.com> <20141207162157.27cf418f@pws-pc.ntlworld.com> <141207150140.ZM24076@torch.brasslantern.com> 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 Sun, 07 Dec 2014 15:01:40 -0800 Bart Schaefer wrote: > On Dec 7, 4:21pm, Peter Stephenson wrote: > } > } That's probably the way to go --- my gut feel is the behaviour of the > } other form of trap is too far from what we need to make it a good > } starting point. > > I took a look through _main_complete and it does quite a bit of saving and > restoring of global completion settings e.g. in order to implement zstyles. > None of it is nicely isolated, i.e., we're going to need several always- > blocks -- and/or possibly some things declared "local", which I'm not sure > why was never done in the first place -- or else a significant rewrite. I'm probably missing a lot, but it struck me that if you're aborting out of completion completely, as it were, then the stuff that doesn't get executed doesn't typically matter all that much. The stuff you really want to get right on exit --- options, IFS, etc. --- is already local. Beyond that I couldn't offhand say which the most important things to restore were. If you aborted completion, did you want to set _lastcomp or do you actually want to steer clear of setting it? pws