RE: Passsing descriptions down in completion functions

[Borzenkov Andrey <Andrey.Borzenkov@siemens.com>]

> On 9 Jan, you wrote:
> >
> > Well, I started to look into these functions and immediately hit some
> > problems:
> >
> > AIX/Type/_object_classes:
> >
> > _wanted objectclasses expl 'object class' \
> >    _files -W ${ODMDIR:-/etc/objrepos} -g '^*.vc'
> >
> > Here is just no place where I could stuff the magic "-". Granted, this
> one
> > does not pass arguments it receives but in general I do not see why it
> > should not do it.
> 
> I think you can put the "-" on the end of the line like this:
>   _wanted ... \
>      _files -W ${ODMDIR:-/etc/objrepos} -g '^*.vc' "$@" -
> 

But you cannot know in advance how _arbitrary_ completion function would
react to stray "-"

> > Base/Utility/_sub_commands
> >
> > if [[ CURRENT -eq 2 ]]; then
> >   _wanted commands expl command compadd "$@"
> > else
> >   _message 'no more arguments'
> > fi
> >
> > almost the same problem. In this case arguments contain both description
> and
> > matches so I have no way to stuff "-" in between.
> 
> That's a slightly unusual case because any matches passed to
> _sub_commands could be thought of as not being arguments to compadd to
> be passed on in the traditional sense. It is probably best handled by
> passing a "-" in the calling function.
> 

Snowball effect :(

> I agree that this isn't particularly ideal though. I remember Sven
> saying something about rethinking the way compadd options are passed
> but I was mostly thinking in terms of suffixes and not descriptions.
> It'd be wise to think in terms of all the compadd options and how they
> are passed around in coming up with a good solution.
> 

Yep. I was thinking mostly not about special way to pass arguments (unless
absolutely needed) but rather about documented discipline. Approximately

- every completion function (i.e. function that generates matches, directly
or indirectly) must accept all compadd options, must not change their
semantic and must pass them down to any other function it calls (except as
noted below). It limits options, available for private use, but in general I
hope usage of special options should not be widespread. Or we can reserve a
special option for quoting, like gcc does it

_foo ...-normal compadd options... -X -my-option -X my-option-argument
...-normal compadd options...

(-X is taken, I know). This is relatively easy to do assuming all functions
are using zparseopts

- low level completion utilities _never_ modify passed options, it is simply
not their business.

> A variant of your _all_labels suggestion is perhaps not a bad idea. I'd
> want to be able to override any passed descriptions in some cases.
>

then do it in completion function that actually needs it (I presume it is
actually a minority). Replace passed arguments with your own. This needs
some utility, we just need to think about the best way to do it. Probably as
an option to zparseopts or something like

zmergeopts [options] current new

where options would be "override", "preserve" and probably more.

This allows such functions as _wanted (or _all_labels) to extract options
from passed command and possibly merge them with generated description if
needed. Extracting options may need some extra utility as well.

Any comments?

-andrey