From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17850 invoked from network); 18 Jul 2001 17:21:09 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 18 Jul 2001 17:21:09 -0000 Received: (qmail 24332 invoked by alias); 18 Jul 2001 17:21:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15413 Received: (qmail 24315 invoked from network); 18 Jul 2001 17:20:59 -0000 Sender: kiddleo Message-ID: <3B55C579.A353D62B@u.genie.co.uk> Date: Wed, 18 Jul 2001 18:20:57 +0100 From: Oliver Kiddle X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.15 i686) X-Accept-Language: en MIME-Version: 1.0 To: zsh-workers@sunsite.dk Subject: Re: PATCH: Re: long/short options References: <200107181307.PAA07497@beta.informatik.hu-berlin.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 -- 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 -. 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