Re: return code of _arguments

Re: return code of _arguments

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Mar 23, 11:33pm, Oliver Kiddle wrote:
> } Subject: return code of _arguments
> }
> } If my understanding is correct the test [[ $? = 300 ]] after _arguments
> } is going to be equivalent to the test [[ -n $state ]]?
> 
> I suggested getting rid of the 300 return code once before.

Hm.  We could of course add an option to _arguments to make it return
300 when needed.  Non-_arguments-wrappers would call it without the
option...


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: return code of _arguments

[Oliver Kiddle]

--- Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote: > 
> > On Mar 23, 11:33pm, Oliver Kiddle wrote:
> > } If my understanding is correct the test [[ $? = 300 ]] after
> _arguments
> > } is going to be equivalent to the test [[ -n $state ]]?

I gather that the reason I was wrong there is because $state may
contain something before the call to _arguments (an may not be a local)
and without ->state actions, it would be unchanged.

> Hm.  We could of course add an option to _arguments to make it return
> 300 when needed.  Non-_arguments-wrappers would call it without the
> option...

I think doing something like this would definitely be a good idea. I
think it is better if the functions for user commands (like _bzip2) are
kept simpler at the expense of things like _arguments and _x_arguments.
I suppose the latter will also need to take the new option and when
called without it will need to use compstate[nmatches].

Oliver

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

return code of _arguments

[Oliver Kiddle]

In a couple of instances, I realised that despite _complete finding
matches, the _approximate completer was also being given a go. For
example, bzip2 --k<tab> was offering loads of other things besides
--keep.

The basic cause of this is that _bzip2 doesn't handle return codes of
300 from _arguments. This is a problem for any completion function
which uses a state machine action for any non-option spec (the *:... or
1:... specs) and is followed by && or || to determine the return code.
There are a good few.

If my understanding is correct the test [[ $? = 300 ]] after _arguments
is going to be equivalent to the test [[ -n $state ]]? The test appears
only twice - in _x_arguments and _xt_arguments so maybe this 300
feature isn't as useful as first anticipated by Sven. I therefore
wonder that the best thing to do here wouldn't be to remove the 300
return-code feature of _arguments and adapt the two functions which
rely on it.

Once we've resolved this, I'll rethink through the return codes for
many of the functions. In cases like _bzip2, the && return 0 is
actually quite handy because you need to use '--' first to compress
files whose names start with a -. If one of the options matched, the
current word must start with a - so we are better not to be completing
files. That said, I'd bet there are a number of functions where return
0 is used but we should be doing ret=0 -- especially any written by me
I fear.

Oliver

Re: return code of _arguments

[Bart Schaefer]

On Mar 23, 11:33pm, Oliver Kiddle wrote:
} Subject: return code of _arguments
}
} If my understanding is correct the test [[ $? = 300 ]] after _arguments
} is going to be equivalent to the test [[ -n $state ]]?

I suggested getting rid of the 300 return code once before.

Back in zsh-workers/12475, Sven wrote:
> 
> No. The special return value is used by the wrappers around _arguments 
> such as _x_arguments. And there we *need* to be able to distinguish
> the cases (to keep the special parameters from being reset).
> 
> And anyway, the problem is not with the return value, since, as you
> observed, we use $state for tests anyway. The problem is that with
> ->state actions _arguments may have to generate matches (the options)
> and it can't know if the caller adds more matches. What I wanted is an 
> easier way for calling functions to distinguish this from the case
> where _arguments generates real matches (by executing one of the other 
> forms for actions). Currently this can be done by relying on the
> return value to test if `real' matches (not only options) were
> generated and then use $state to find out if a state has to be handled 
> and *there* use $compstate[nmatches] to find out if options were
> completed. If needed, and it is seldom needed because in most cases
> the state doesn't have to be handled in a loop.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net