Bugs thrown up by _perforce

[Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxx>]

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-<subcommand> 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 <pws@xxxxxxxxxxxxxxxxxxxxxxxx>
Work: pws@xxxxxxx
Web: http://www.pwstephenson.fsnet.co.uk