From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-33870-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 21731 invoked by alias); 5 Dec 2014 18:13:37 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 33870
Received: (qmail 18615 invoked from network); 5 Dec 2014 18:13:36 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
	SPF_HELO_PASS autolearn=ham version=3.3.2
X-AuditID: cbfec7f4-b7f126d000001e9a-0b-5481f5cd0a51
Date: Fri, 05 Dec 2014 18:13:30 +0000
From: Peter Stephenson <p.stephenson@samsung.com>
To: Zsh Hackers' List <zsh-workers@zsh.org>
Subject: Re: Interrupting globs (Re: Something rotten in tar completion)
Message-id: <20141205181330.2b458b46@pwslap01u.europe.root.pri>
In-reply-to: <141205100632.ZM508@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>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsVy+t/xy7pnvzaGGMy5IGJxsPkhkwOjx6qD
	H5gCGKO4bFJSczLLUov07RK4Mi6cWc9S8IC94t25d4wNjN1sXYycHBICJhLH+s4xQ9hiEhfu
	rQeLCwksZZQ49Ui2i5ELyF7CJPHoWTMLhLONUeL/9gdgVSwCqhKfP2xjAbHZBAwlpm6azdjF
	yMEhIqAt0f5RDCQsLOAhcWDLH7ASXgF7iWsPZrOD2JwCFhJf1l1jhZg5j1li14MpYDP5BfQl
	rv79xARxkb3EzCtnGCGaBSV+TL4HNohZQEti87YmVghbXmLzmrfMEFerS9y4u5t9AqPQLCQt
	s5C0zELSsoCReRWjaGppckFxUnquoV5xYm5xaV66XnJ+7iZGSNB+2cG4+JjVIUYBDkYlHt4L
	1o0hQqyJZcWVuYcYJTiYlUR4k2cDhXhTEiurUovy44tKc1KLDzEycXBKNTCqmOomrfp0/ubD
	8D8qTSmNWVeKy2aXtaX79Ty49r2g9vpNu9bbbVJnr3O9EtY6kP9g7tSDnh1qztxTRHJ2bjL5
	6G/r3830VC1+vzPztiszu+tiNH48mre08UmipvPd05HFH9Jbg/636kifNC+dMp8/pkm1eDuX
	3I0Wps3fCp+yCz9ZVOlgeFSJpTgj0VCLuag4EQCHoJr+OAIAAA==

On Fri, 5 Dec 2014 10:06:32 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Not speaking directly for completion, but withOUT the above patch:
> 
> % : /**/*(/)
> 
> is not interruptible.  WITH the above patch, the recursive glob can be
> interrupted.

Yes, I agree your patch is a good idea, too.  I did see a lot of
unnecessary goings on in scanner() even after errflag was being set
properly.

> } 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.

pws