_arguments description problem

_arguments description problem

[Borsenkow Andrej]

_arguments documentation suggests that description given in
option/argument specification is shown when values are completed. In
most cases they are not. The simple reason is, many "low-level"
functions that are called out of _arguments finally end up with
something like (_users):

_wanted users expl user compadd "$@" -k userdirs

and _wanted in effect overrides any arguments given to _users. It means,
that whatever top-level _arguments call specifies, _any_ call to _users
will show description "user" and not description given to _arguments.
Easy to see in smbclient - 

'(2)-U+[specify username]:username:_users'
                          ^^^^^^^^

but{pts/0}% smbclient -U adm
Completing user
           ^^^^
adm          dnscache     httpd-naat   operator     root         tinydns

Which means that _wanted (and related functions) probably needs some way
to know if it needs to setup description or not. I wonder, does it make
sense to parse arguments (in this case "$@" -k userdirs) and if standard
completion options are already there, do not override them? Seems like
the least intrusive solution.

-andrej

Re: _arguments description problem

[Sven Wischnowsky]

Borsenkow Andrej wrote:

> ...
> 
> Which means that _wanted (and related functions) probably needs some way
> to know if it needs to setup description or not. I wonder, does it make
> sense to parse arguments (in this case "$@" -k userdirs) and if standard
> completion options are already there, do not override them? Seems like
> the least intrusive solution.

Actually, I have already added a mechanism for that, see the
description for _all_labels in the docs (which is referred to under
_requested, which is referred to under _wanted). If the command-args
given to any of these functions contains a `-', the options are added
before it, if the hyphen is the last argument, it is replaced with the
options. And since latter options override earlier onces for compadd,
clean functions should probably use things like:

  _wanted users expl user compadd "$@" -k userdirs -

(note the added `-' at the end)

But I have to admit that I always forget to do that, too. Sorry.


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

RE: _arguments description problem

[Borsenkow Andrej]

> 
> Borsenkow Andrej wrote:
> 
> > ...
> >
> > Which means that _wanted (and related functions) probably needs some
way
> > to know if it needs to setup description or not. I wonder, does it
make
> > sense to parse arguments (in this case "$@" -k userdirs) and if
standard
> > completion options are already there, do not override them? Seems
like
> > the least intrusive solution.
> 
> Actually, I have already added a mechanism for that, see the
> description for _all_labels in the docs (which is referred to under
> _requested, which is referred to under _wanted). If the command-args
> given to any of these functions contains a `-', the options are added
> before it, if the hyphen is the last argument, it is replaced with the
> options. And since latter options override earlier onces for compadd,
> clean functions should probably use things like:
> 

I would not call this really clean :-) It is a workaround I admit but
not a really clean solution.

>   _wanted users expl user compadd "$@" -k userdirs -
> 
> (note the added `-' at the end)
> 
> But I have to admit that I always forget to do that, too. Sorry.
> 

bor@itsrm2% grep -r _wanted | wc -l
    300 
bor@itsrm2% grep -r _wanted | grep -- ' - ' | wc -l
     26

so over 90% of all functions do not use it.

I really believe that cleaner and better way would be to parse options.
Is it possible to do it in one place only? 

-andrej

RE: _arguments description problem

[Sven Wischnowsky]

Borsenkow Andrej wrote:

> ...
> 
> I would not call this really clean :-) It is a workaround I admit but
> not a really clean solution.
> 
> >   _wanted users expl user compadd "$@" -k userdirs -
> > 
> > (note the added `-' at the end)
> > 
> > But I have to admit that I always forget to do that, too. Sorry.
> > 
> 
> bor@itsrm2% grep -r _wanted | wc -l
>     300 
> bor@itsrm2% grep -r _wanted | grep -- ' - ' | wc -l
>      26
> 
> so over 90% of all functions do not use it.
> 
> I really believe that cleaner and better way would be to parse options.
> Is it possible to do it in one place only? 

That wouldn't be much cleaner, actually, because there would have to
be an option to select or de-select this behaviour because we don't
always want it -- at least I know that I wrote some functions where I
intentionally didn't use `-', in cases where the lower level functions
just knew better what to produce as descriptions.

So that is one case where just counting lines gives wrong results. Two
other cases are: functions that are not intended to be used as helper
functions (and those are responsible for many of the uses of _wanted)
and cases where the `-' might be on a second line. I don't know how
many cases fall into the second category, but a bit of grep and wc
shows 131 cases where the line with _wanted ends in a backslash.


But of course, anyone is free to hack on the completion code -- always
was. The best place would probably be _all_labels, the place where we
now do the search for `-'. And make sure to check the uses of _wanted
so that we don't use stuff we want to have.


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de