Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: Re: long/short options
- X-seq: zsh-workers 15413
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: PATCH: Re: long/short options
- Date: Wed, 18 Jul 2001 18:20:57 +0100
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <200107181307.PAA07497@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Sender: kiddleo
Sven Wischnowsky wrote:
>
> I just had to play a bit today...
>
> This makes _describe and compdescribe try to group matches with the same
> description. I've used Bart's first suggestion, i.e. it really searches
Great. Cheers Sven.
gzip --<tab> seems to just be offering --fast and --best. It seems to be
all options up to but not including the first where we have a reused
description. It is fine with just gzip -<tab>. Similarly for other
commands.
There is possibly scope for _arguments parsing of --help output (as used
by _gnu_generic) to make better use of output where options are listed
together, i.e. looking something like this:
-?, --help display this option help
> I've also made sure that in menu selection the entries for all options
> belonging together are shown together. Unfortunately that meant to make
> all those strings start with the same (the list of options), which is a
> bit ugly. If you try it, you'll see that I at least changed the
> descriptions of the second to n'th string to be `|' which sorts in after
> most normal characters and hence makes the list look not too stupid.
> I'm open to every suggestion to make this even more pleasing -- the best
> we could get is probably to make the second to n'th entry show only the
> i'th option and something like ` - " - ', but for that we would have to
> sort the strings and add them as an unsorted group (i.e. mess with the
> compadd-options _describe gets from its caller). Certainly doable,
> though.
This bit doesn't seem entirely ideal. For menu selection what might be
better would possibly be if the separate options were highlghted
separately instead of having to expand it out. I think it would also be
good if there was a style so the user could perhaps select whether they
wanted selection to pick the long or short option (as I think someone
else suggested). With the current implementation, a centred ditto mark
(") might be better than the pipe (|). It might also be better if when
expanding it, you just got `-H' and `--help' on each line instead of
`-H, --help' duplicated.
We have a lot of completion functions where we've not used the braces to
offer descriptions for both long and short options. Specifying
descriptions for only short options seems to have been fairly common.
Converting them will be a tedious job which I will get round to if
nobody else does it first but I have roughly zero spare time at the
moment.
One other thing which this has reminded me of is that I would quite like
it to be able to remove from the completion listings extra options which
some commands have like gzip's --to-stdout which is the same as
--stdout. So some sort of style which says list/complete only the
canonical form of something and some way of saying in _arguments that an
option is just an extra synonym. However with this new patch of,
--to-stdout is now less annoying anyway because it isn't there with a
full description taking a whole line.
Oliver
Messages sorted by:
Reverse Date,
Date,
Thread,
Author