grouping inverses and sorting in completion lists (was _chflags)

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Sven wrote:
> 
> > > > > 1. How can I prevent _values from sorting the values?
> > > Er. Sven? -V doesn't work so you probably can't. Why do you want to?

> > Can anyone else please enlighten me if there is a
> > style to affect the sort order?

> Currently not.  It could be added without too much work, but I, too,
> wonder why anyone would want that.  Especially with functions like this
> one, where the specs are put together in steps based on OS version. 
> Finding stuff in a sorted list should be a lot easier.

> Hm.  Maybe we could add a set of styles like `file-sort' (for options,

I don't think it is necessary at the style level: I've never wanted it
and here (_chflags) it was only wanted to group options with their
inverse. The only thing I have needed was to have a list sorted
correctly numerically (such as in _subscript for array indexes) and
this is better done from the functions than from a style. It might be
worth rethinking the compadd options with respect to sorting though.

> > > 2. How can I let zsh automatically add `R' when one chooses -[LHP]?

> I can't think of an easy way to get this either.  But it sounds
> interesting because it sounds like something that could be generalised. 
> Support for `suggested' other completions.  Hm...

I can't think of much to suggest here.

> > In 4.1 this looks roughly like this when completed:
> > > file flag
> > dump    nodump    --  backup file when dump(8) is next run
> 
> It would be `nodump dump', wouldn't it?  I've been thinking about this

Yes.

> when I wrote the grouping code (and then forgot to mention it again). 
> Maybe we should make the code watch out for prefixes `-no', `no', `no-'
> and the like (`-enable', `-disable', `-with', `-without',...?).  The one
> without the prefix (with one of the prefixes...) would then be put in
> front.  We could even make it shorten the display string for the other
> form(s), e.g. `dump no...   -- backup ...' or `dump  [no]   -- ...'.
> Heck, we could even make it display something like `dump  [yes] [no] ...'
> or anything else because display string are completely separate from
> match strings.

Something like that would be very good. To automatically detect
inverses might have problems in that many words start with `no' and it
would be nice to be flexible enough to allow other forms. There might
be cases where `de', `in' or `un' are used instead of `no' or maybe two
totally different words. One possibility (which would need further
refining) would be an option to _arguments which would be roughly like:
-I '/--enable\(*\)/--disable\1/'
The idea being that if this (sed like) substitution translates an
option to match one of the other options, that other option can be
taken to be its inverse.

As for how to display it, shortening the display string would be very
nice. It also makes it clearer which is the negative sense which is
helpful if the description is written in a positive form. I'm not so
sure about the [yes] [no] idea. Here are some possibilities it would
ideally need to deal with:

--with-gnu-ld  without  --
--disable-nls  enable   --
dump           no...    --
-g             +g       -- e.g. for typeset
--no-filename --with-filename   -h   -H   -- e.g. for grep

Of course, it would be quite possible that the two inverse options are
given different descriptions. What it could do is select one of them
(either the shortest description or the description for the option on
the left) to display. Then if the other option was selected, the
description would change.

Cases like the latter one for grep might be messy so this needs more
thought. What would currently happen if there was loads of options
with the same description.

Oliver