Re: _chflags

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Oliver Kiddle wrote:

> ...
> 
> > And I have a couple of questions:
> > 
> > 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? To
> group flags with their no variants by any chance? In the latest zsh 4.1,
> it might be better to use '(noarch arch)'{arch,noarch}'[archived flag]'
> which would put arch and noarch on the same line with a shared
> description.
> 
> You can use styles to group no and non-no flags separately if that is
> what you want to do. 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,
values, pids, jobs, ...) if we can come up with reasonable sort criteria
for each of them.  That would then make sense (for menu completion and
selection).

> > 2. How can I let zsh automatically add `R' when one chooses -[LHP]?
> 
> Again, I don't know/don't think it can be done. You would need to get it
> to be added as an (auto-removable) suffix which I don't think _arguments
> can handle.

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...

> > (( $+functions[__chflags] )) ||
> > __chflags() {
> 
> I take it that you copied this from _kld or _bsd_pkg which is fine. I
> prefer to use states with _arguments to defining separate functions
> within completion functions. In the case of _chflags, neither is
> actually necessary.

(Aside: for more complex things I actually sometimes prefer
sub-functions because than _arguments can be kept in control.)

> ...
> 
> About these descriptons again: I'm not too sure how useful the
> description `set the dump flag' is although that type of description is
> quite common for zsh completions.

Yes we (and foremost I) have been a bit lazy sometimes... but then I'm
quite happy that we have these descriptions at all.

> ...
> 
> Note that that description for the dump flag could be completely wrong.
> 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
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.

Opinions, anyone?


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx