* RE: Passsing descriptions down in completion functions
@ 2003-01-09 16:26 Borzenkov Andrey
2003-01-09 17:09 ` Oliver Kiddle
0 siblings, 1 reply; 8+ messages in thread
From: Borzenkov Andrey @ 2003-01-09 16:26 UTC (permalink / raw)
To: 'zsh-workers@sunsite.dk'
>
> The general question - should completion functions ever accept (be used
> with) other options than compadd? If not the above is perfectly valid and
> probably more simple that modifying every single function. If yes, here is
> the list of functions that use _wanted without '-'.
>
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.
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.
-andrey
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Passsing descriptions down in completion functions
2003-01-09 16:26 Passsing descriptions down in completion functions Borzenkov Andrey
@ 2003-01-09 17:09 ` Oliver Kiddle
2003-01-10 8:10 ` Borzenkov Andrey
0 siblings, 1 reply; 8+ messages in thread
From: Oliver Kiddle @ 2003-01-09 17:09 UTC (permalink / raw)
To: zsh-workers
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' "$@" -
> 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.
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.
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.
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.
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: Passsing descriptions down in completion functions
2003-01-09 17:09 ` Oliver Kiddle
@ 2003-01-10 8:10 ` Borzenkov Andrey
2003-01-14 15:43 ` Oliver Kiddle
0 siblings, 1 reply; 8+ messages in thread
From: Borzenkov Andrey @ 2003-01-10 8:10 UTC (permalink / raw)
To: 'Oliver Kiddle', zsh-workers
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Passsing descriptions down in completion functions
2003-01-10 8:10 ` Borzenkov Andrey
@ 2003-01-14 15:43 ` Oliver Kiddle
0 siblings, 0 replies; 8+ messages in thread
From: Oliver Kiddle @ 2003-01-14 15:43 UTC (permalink / raw)
To: Borzenkov Andrey; +Cc: zsh-workers
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Passsing descriptions down in completion functions
@ 2003-01-09 13:17 Borzenkov Andrey
[not found] ` <32149.1042120127@finches.logica.co.uk>
0 siblings, 1 reply; 8+ messages in thread
From: Borzenkov Andrey @ 2003-01-09 13:17 UTC (permalink / raw)
To: 'zsh-workers@sunsite.dk'
Either I do not understand something basic or it does not work (and probably
has never working really).
Simple example.
bor@itsrm2% functions _foo
_foo () {
_arguments -s "-p[some option]:argument for this option:_hosts"
}
bor@itsrm2% compdef _foo foo
bor@itsrm2% foo -p TAB
bor@itsrm2% foo -p D248H032
Completing host
^^^^ should it not be "argument for that option"?
D248H032 GH4090Y0 anyhost
...
It is clear what happens:
+_arguments:340> _hosts -J option-p-1 -X '%BCompleting argument for this
option%b'
this sounds good, but later on ...
+_all_labels:37> compadd -J hosts -X '%BCompleting host%b' -M
'm:{a-zA-Z}={A-Za-z} r:|.=* r:|=*' -J option-p-1 -X '%BCompleting argument
for this option%b' -a hosts
Oops, description is now lost.
Quoting documentation:
If the ACTION starts
with a space, this list of words will be invoked unchanged,
otherwise it will be invoked with some extra strings placed after
the first word which can be given as arguments to the compadd
builtin command and which make sure that the MESSAGE given in the
description will be shown above the matches.
So, is it a bug or not?
-andrej
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-01-14 15:41 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-09 16:26 Passsing descriptions down in completion functions Borzenkov Andrey
2003-01-09 17:09 ` Oliver Kiddle
2003-01-10 8:10 ` Borzenkov Andrey
2003-01-14 15:43 ` Oliver Kiddle
-- strict thread matches above, loose matches on Subject: below --
2003-01-09 13:17 Borzenkov Andrey
[not found] ` <32149.1042120127@finches.logica.co.uk>
2003-01-09 14:04 ` Oliver Kiddle
2003-01-09 15:09 ` Borzenkov Andrey
2003-01-09 16:11 ` Oliver Kiddle
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).