Re: long/short options

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> ...
> 
> Anyway, that aside, obviously it would require a change to _describe,
> but would it really need a change in the C code? 

Well, ok, it doesn't, but it might be easier to write because it's the
C-code that builds the strings to display.

> Taking this fragment
> as an example:
> 
>     _arguments -s \
>         '(-b -t --text)--binary[Unix line endings LF]' \
>         '(--binary -t --text)-b[Unix line endings LF]'
> 
> One solution would be to have _describe actually scan the description
> strings looking for duplicates, and condense them in the listing by
> adding one option to the display string for the other and dropping the
> duplicate from the list of completions (i.e., the duplicate would get
> passed to `compadd -n ...').  That would have the effect I mentioned,
> that you'd see `-b, --binary ...' but only be able to menu-select
> `--binary'.

Strings added with -n are intentionally made visible in menu selection,
by the way.

> That still means the caller of _arguments has to supply all the duplicate
> description strings for _describe to search for.  So another possibility
> would be for the caller to use something like:
> 
>     _arguments -s \
>         '(-b -t --text)--binary[Unix line endings LF]' \
>         '(--binary -t --text)-b[(--binary)]'
> 
> Here _describe would parse off the leading parenthesized string from the
> description.  If the option named in the parens is among the possible
> completions, it prepends the option name and a comma to the description
> string of the option named in the parens and uses `compadd -n' for the
> option that has this special description.  Otherwise it adds the option
> and the rest of the description (after the parens) as usual.  [This is
> to handle a strange special case where you have two options that mean
> the same thing individually but have different exclusion lists, e.g. one
> of them has a new meaning when in combination with some third option.]

Hm, the first way above would be easier for users because they could uses
brace expansions as I suggested to Andrej some time ago.

> Both of these approaches mean that _describe has to make an extra pass
> over the options before `compadd'ing them.  And I'm really not sure how
> difficult they actually would be to implement.

Now that you've done the thinking -- not too hard, actually.  I would
still put it in the C-code because that has to separate the strings from
the descriptions and look at them closely anyway (and searching for
duplicate descriptions should be much faster there).

Hm we could then add a style to _describe so that users can select if
they want 1) matches with the same description put on one line or not
and 2) if they want them to appear as two matches in menu selection or
if the shorter or longer one should just be ignored.  Although 2) may go
too far because _describe has no information about things like option-
arguments or exclusion lists that may be different.


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx