Re: Bugs thrown up by _perforce

[Oliver Kiddle <okiddle@yahoo.co.uk>]

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.