zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh-workers@sunsite.dk
Subject: Re: PATCH: Re: long/short options
Date: Wed, 18 Jul 2001 18:20:57 +0100	[thread overview]
Message-ID: <3B55C579.A353D62B@u.genie.co.uk> (raw)
In-Reply-To: <200107181307.PAA07497@beta.informatik.hu-berlin.de>

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


  parent reply	other threads:[~2001-07-18 17:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-12 16:01 Andrej Borsenkow
2001-07-13  8:07 ` Sven Wischnowsky
2001-07-13 17:01   ` Bart Schaefer
2001-07-16  7:14     ` Sven Wischnowsky
2001-07-18 13:07       ` PATCH: " Sven Wischnowsky
2001-07-18 13:46         ` Andrej Borsenkow
2001-07-18 13:51           ` Sven Wischnowsky
2001-07-18 13:59             ` Andrej Borsenkow
2001-07-18 17:20         ` Oliver Kiddle [this message]
2001-07-19  8:36           ` Sven Wischnowsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B55C579.A353D62B@u.genie.co.uk \
    --to=okiddle@yahoo.co.uk \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).