From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4843 invoked from network); 25 Feb 2003 13:07:55 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 25 Feb 2003 13:07:55 -0000 Received: (qmail 22389 invoked by alias); 25 Feb 2003 13:07:28 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 18290 Received: (qmail 22376 invoked from network); 25 Feb 2003 13:07:27 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 25 Feb 2003 13:07:27 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [62.189.183.235] by sunsite.dk (MessageWall 1.0.8) with SMTP; 25 Feb 2003 13:7:26 -0000 Received: from exchange01.csr.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 25 Feb 2003 13:14:30 +0000 Received: from csr.com (tinky-winky.csr.com [192.168.144.127]) by exchange01.csr.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DQ473FPS; Tue, 25 Feb 2003 13:07:38 -0000 To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: Bugs thrown up by _perforce In-reply-to: "Oliver Kiddle"'s message of "Mon, 24 Feb 2003 15:50:31 +0100." <13505.1046098231@finches.logica.co.uk> Date: Tue, 25 Feb 2003 13:07:25 +0000 Message-ID: <22979.1046178445@csr.com> From: Peter Stephenson Oliver Kiddle wrote: > [_next_tags always inserts an unambiguous completion] > > You can fix this by changing the ins=unambiguous line to just ins= so > that compstate[insert] remains empty but this changes _next_tags > behaviour in other cases. I'll test this out. > I'm only an occasional _next_tags user so am not sure what the ideal > behaviour would be. Does anyone want _next_tags to actually complete > stuff ever? I can't see why --- certainly not treat it as an unambiguous insertion, fait accompli. You can't even see what it's going to complete next. > [an _arguments --- or any inner tags loop --- screws up _next_tags] > > I think the problem is that argument-rest is finding its way into > _next_tags_not. > > Both foos and bars have the argument-rest tag for the first tag loop so > both are excluded by _next_tags. > > So what should _next_tags do when we have nested tag loops? Advance inner > before outer? Advance both together? Or something different entirely? Um. I'm still a bit vague as to how all this works. Can we prevent this behaviour happening with argument-rest? After all, it's being smuggled in behind our back anyway --- it's not specified either in the styles, nor in the list of tags I'm explicitly generating. Can we make the system remember we're in a nested loop? And then inside it can be more lenient? Or some combination of the tow? Or something? I don't think I'm going to be much help here. -- Peter Stephenson Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. **********************************************************************