From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5647 invoked from network); 24 Feb 2003 14:48:34 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 24 Feb 2003 14:48:34 -0000 Received: (qmail 25140 invoked by alias); 24 Feb 2003 14:47:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 18281 Received: (qmail 25133 invoked from network); 24 Feb 2003 14:47:23 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 24 Feb 2003 14:47:23 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [193.109.254.147] by sunsite.dk (MessageWall 1.0.8) with SMTP; 24 Feb 2003 14:47:22 -0000 X-VirusChecked: Checked X-Env-Sender: kiddleo@logica.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1046098037!2936 Received: (qmail 2829 invoked from network); 24 Feb 2003 14:47:18 -0000 Received: from iris.logica.co.uk (158.234.9.163) by server-6.tower-27.messagelabs.com with SMTP; 24 Feb 2003 14:47:18 -0000 Received: from finches.logica.co.uk ([158.234.142.11]) by iris.logica.co.uk (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA16506 for ; Mon, 24 Feb 2003 14:47:16 GMT X-Authentication-Warning: iris.logica.co.uk: Host [158.234.142.11] claimed to be finches.logica.co.uk Received: from finches.logica.co.uk (localhost [127.0.0.1]) by finches.logica.co.uk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h1OEoVg13507 for ; Mon, 24 Feb 2003 15:50:31 +0100 To: zsh-workers@sunsite.dk (Zsh hackers list) In-reply-to: <20030223160208.448A91B76A@pwstephenson.fsnet.co.uk> From: Oliver Kiddle References: <20030223160208.448A91B76A@pwstephenson.fsnet.co.uk> Subject: Re: Bugs thrown up by _perforce Date: Mon, 24 Feb 2003 15:50:31 +0100 Message-ID: <13505.1046098231@finches.logica.co.uk> Sender: kiddleo@logica.com On 23 Feb, Peter wrote: > This has thrown up two quite annoying bugs in the use of `_next_labels'. > The first is that _next_tags always accepts a single completion > possibility at the point it's reached (not if it's the initial > possibility). Here's a suitable set up which will act as the basis for > both bits. > > _foos() { > local arr > arr=(up) > _describe -t foos 'type foo' arr > } > _bars() { > local arr > arr=(north south east west) > _describe -t bars 'type bar' arr > } > _foobar() { > _alternative foos:foo:_foos bars:bar:_bars > } > compdef _foobar foobar > > Completion after `foobar' works fine so far, offering foos and bars > grouped however you ask it to. Now, let's tell it to offer us foos > before bars: > zstyle ':completion:*:foobar:*' tag-order foos bars > `foobar ^D' is OK; ^xn for _next_tags works the first time, > switching from foos to bars. However, when you switch back the `up' is > always completed; you can't switch again. This is despite the fact that > you are still listing --- the system evidently remembers this, because > with menu completion, nothing is inserted for the bars even though the > list is displayed. I don't think it is remembering that it is listing - nothing is inserted for the bars only because there is no common unambiguous prefix for them. 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. Possibly for the better: I wonder that the initial definition of _next_tags shouldn't perhaps be based on list-choices instead of complete-word (though playing with compstate mostly overrides that). You might be able to make this configurable with a style and use things like $LASTWIDGET to see whether we are listing or completing. 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? > The second bug shows up with a similar set up; I'll remove the trigger > for the first bug. Note the extra level of function calling. > > _foos() { > local arr > arr=(up down left right) > _describe -t foos 'type foo' arr > } > _bars() { > local arr > arr=(north south east west) > _describe -t bars 'type bar' arr > } > _foobar_cmd() { > _alternative foos:foo:_foos bars:bar:_bars > } > _foobar() { > _arguments '*::foobar command:_foobar_cmd' > } > compdef _foobar foobar > > Again, this works fine with no tag-order defined. This time, when you > define the tag-order as above, _next_tags fails completely --- there is > no way to move from the foos onto the bars. Hence my statement above > that this makes _next_tags essentially useless for command arguments. I think the problem is that argument-rest is finding its way into _next_tags_not. You can replace your _foobar() above with just _foobar() { _wanted foobars expl 'foobar command' _foobar_cmd } and it still fails the same way so it is nothing to do with _arguments and command arguments and everything to do with nested tag loops. 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? > Altering _foobar to use the state mechanism: > seems to work around the problem. It was too much like hard work to get > _perforce to do this this time round. That makes sense: _arguments can't do tag loops for states. And, note that you are ignoring any value set in $context by _arguments here. > I won't be looking at the source of these problems since the code for > this sort of thing does my head in. Unless Oliver or Bart has some > ideas or Sven surfaces we may be a bit stuck. Hopefully those ideas at least give us something to work with. Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.