Re: _arguments problems

[Tanaka Akira <akr@xxxxxxxxxxx>]

In article <200002040959.KAA23014@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
  Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx> writes:

> > is27e1u11% _tst () { _arguments '-a' '*::rest:_tst2' }
> > is27e1u11% _tst2 () { compadd - '-b' }
> > is27e1u11% tst arg -<TAB>
> > -b 
> > -a 
> > 
> > This completes `-a' and `-b' but it shouldn't completes `-a'.
> 
> Hm. I see why you think it shouldn't and it can be achieved by
> applying the first hunk below.
> 
> *But* if we do that there wouldn't be a way to get at the options in
> cases like this one (ok, it works with longer options but with short
> ones like these one would have to type the whole option to complete
> it). I'm really not sure if this is a good idea, I could only convince 
> myself to build that patch because one can always set the
> prefix-needed style to false for such commands.
> 
> I'd like to hear other opinions: does anyone think that this might
> surprise users? Or maybe I'm worrying too much about to special a
> case...

I intended to use that for _cvs.  Since valid options are quite
different before and after non-option first argument, it is trouble
that _arguments in _tst1 and _cvs completes options over non-option
first argument.  If _arguments behaves so, _cvs completes global
options for subcommands as:

Z(2):akr@is27e1u11% cvs add -<TAB>
option
--allow-root      --help-options    -H   -a   -e   -l   -q   -t   -x 
--help            --help-synonyms   -Q   -b   -f   -m   -r   -v   -z 
--help-commands   --version         -T   -d   -k   -n   -s   -w      

Options except `-k' and `-m' are global options and they are only
valid between `cvs' and `add'.

So, I think following behaviour is also problem.

is27e1u11% _tst () { _arguments '-a' '*::rest:(rest)' }
is27e1u11% tst arg -<TAB>
->
is27e1u11% tst arg -a

Because I think _arguments shouldn't completes options after an
argument handled by `*::message:action'.
-- 
Tanaka Akira