Re: Passsing descriptions down in completion functions

[Oliver Kiddle <okiddle@yahoo.co.uk>]

On 10 Jan, Andrey wrote:
>
> > On 9 Jan, you wrote:
> > > 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 "-"

Quoting from Etc/completion-style-guide:

      _all_labels foo expl 'descr...' _combination ... -

    And the `-' will be replaced by the options that are to be given to
    `compadd'.

So if there is one `-' argument and it is the last on the line, it is
removed by _all_labels.

> > > 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 :(

Okay, perhaps _sub_commands should split its options and insert the `-'
itself. It is a sufficiently special case not to worry me.

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

There is an extent to which there is existing documented discipline if
you take Etc/completion-style-guide together with the documentation.
The fact that it was only loosely adhered to being another matter.

> 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

That's a bit like the opposite of the -O option to _arguments for
passing compadd options. I fear it could make the functions less easy
to read relative to just taking care to choose option letters that
aren't compadd options.

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

Depends what you define as "low level". That is easy for something like
_hosts that just completes something. What do you do with a suffix (-S
option) if you're completing the user part in  _user_at_host?

As an aside, I don't like the _files behaviour of appending passed
suffixes to directories instead of a slash.

> > 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

Thinking about "the best way to do it" is the hard part and I've yet to
think of anything which seems better than the current system.

Oliver

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.