Re: problem with _arguments exclusion lists

[Oliver Kiddle <opk@xxxxxxxxxxxxx>]

Sven Wischnowsky wrote:
> 
> ;-) I understood you, really.  But I'm pretty sure there are programs
> that allow other (single letter) options after that `-c', meaning that
> either `-c's argument is the empty string or that it comes in the next
> word.  Or something.  So I still think we need a way to tell _arguments
> that either:
> 
> 1) after all `-x-:...' or `-x+:...' options other options may be
>    completed, or

I suppose this option would involve another option to _arguments like
-W and it would only be useful with -s.

> 2) that after some of those options other options may be completed, or

And, I suppose this would handle commands which are inconsistent in the
way they behave for different options. For the _arguments syntax, I
can't think of much better than some additional random character before
the colon.

I suppose that of these (2) covers more possible situations so is the
most complete but we could have both where the option (as per (1))
specifies a default and the syntax for (2) overrides it. Keeping this in
mind, if (1) is implemented, (2) could be added later if we find
inconsistent commands for which it is needed.

> All that is independent of what we choose to use as the default.  I.e.,
> if we leave the current behaviour the default or if we make completing
> options there the default (unless otherwise specified).

I would probably vote for the current behaviour being the default - that
is not completing other options in this case because it is probably more
common for commands to parse arguments that way and it keeps the number
of matches down.

> Or maybe I'm thinking way to complicated again and we should just make
> it try completing options in such places, too.  If the user has already

Possibly, but I would err on the side of making it not try completing
options in such places. When I type commands, I tend to specify them in
a clear sensible way rather than the most minimal way that command
happens to allow.

> started typing the argument of the option, other option names won't
> match anyway.

True. And if other option names do match, the user might be trying to
complete the option name so it is important that it is added as a
match.

> Leaves only the slight ugliness that `-c<TAB>' would
> offer other single-letter options as possible completions (if _arguments
> was given the -s options), even if the command doesn't allow that after
> options that get an argument.

That is really quite ugly and backs up my feeling that this should not be
the default.

> 3) (what you described) that the argument of option `-x+:...' has to
>    match a certain pattern and if it doesn't match, other options are to
>    be completed there.

I think it is a good idea to maybe complete options only if we fail to
complete the option argument because it avoids the ugliness mentioned
above. Would it be possible to use a tag-order style to put the options
last here?

I wouldn't want to put the pattern in _arguments though. What follows is
a separate issue really so is a bit of a divergence.

As a test, I created an _number like this:
[[ $PREFIX$SUFFIX = [0-9]# ]] || return 1
_message 'number' && return 0
And then used this _arguments:
_arguments -s '-c+:number:_number' '-conf'

Now, if I complete after -co, I get the message:
	No matches for: `number' or `corrections'
What _arguments should do in this case is see the return code from
_number and from it conclude that we are not completing a parameter to
-c because it failed. For (3), it could then complete other single
letter options (it should be adding -conf as a match regardless). This may
be more complicated but is how I think we should be specifying patterns
if we use option (3).

Incidentally, with this when completing after just -c, the message
`number' is displayed to indicate that what is expected is a number. It
does not look up the format style with the descriptions tag and display
it in bold (with my style settings). I think it should because `number'
is a group of matches the same as other things we complete (option,
user etc), it is just that we haven't generated as matches all possible
numbers.

We could have a general function which is called like _message to
say we are completing such and such sort of thing but are not adding the
actual matches because it doesn't make sense to. It could take an option
for specifying a pattern to compare against $PREFIX/$SUFFIX to allow it
to fail when appropriate.

Oliver