From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8949 invoked from network); 23 Feb 2003 16:00:59 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 23 Feb 2003 16:00:59 -0000 Received: (qmail 9352 invoked by alias); 23 Feb 2003 16:00:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 18276 Received: (qmail 9341 invoked from network); 23 Feb 2003 16:00:48 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 23 Feb 2003 16:00:48 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [195.92.193.211] by sunsite.dk (MessageWall 1.0.8) with SMTP; 23 Feb 2003 16:0:47 -0000 Received: from modem-204.double-barred-spinefoot.dialup.pol.co.uk ([62.137.0.204] helo=pwstephenson.fsnet.co.uk) by cmailm4.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 18myYY-0000dk-00 for zsh-workers@sunsite.dk; Sun, 23 Feb 2003 16:00:46 +0000 Received: by pwstephenson.fsnet.co.uk (Postfix, from userid 501) id 448A91B76A; Sun, 23 Feb 2003 16:02:08 +0000 (GMT) Received: from pwstephenson.fsnet.co.uk (localhost [127.0.0.1]) by pwstephenson.fsnet.co.uk (Postfix) with ESMTP id 37F8C1B769 for ; Sun, 23 Feb 2003 16:02:08 +0000 (GMT) To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Bugs thrown up by _perforce Date: Sun, 23 Feb 2003 16:02:03 +0000 From: Peter Stephenson Message-Id: <20030223160208.448A91B76A@pwstephenson.fsnet.co.uk> I'm committing another version of _perforce; I don't think there's enough general interest to warrant posting it, and it's quite a long diff since I've tried to rationalise names (e.g. changelist/changelists to changes) as well as add some features (service=p4- works, dates can be completed) and fixed some bugs (labels and clients after an @ didn't work). This has thrown up two quite annoying bugs in the use of `_next_labels'. The background is that I was trying to use the tag-order style to make the system first throw up changes (i.e. changeset numbers) after an `@' (this acts as a modifier to a filename), then the other possibilities. I ran across two problems. The second is the real killer --- it makes _next_tags virtually useless for command arguments. 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. This is a fairly minor annoyance since in most cases like this there will be more than one completion, and it seems to be possible to delete back to the place you were in and then call next tags. 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. Altering _foobar to use the state mechanism: _foobar() { local context state line typeset -A opt_args _arguments '*::foobar command:->foobar_cmd' if [[ $state = foobar_cmd ]]; then _foobar_cmd fi } seems to work around the problem. It was too much like hard work to get _perforce to do this this time round. 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. -- Peter Stephenson Work: pws@csr.com Web: http://www.pwstephenson.fsnet.co.uk