From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29515 invoked from network); 4 Aug 2001 04:53:20 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Aug 2001 04:53:20 -0000 Received: (qmail 6704 invoked by alias); 4 Aug 2001 04:53:13 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15569 Received: (qmail 6693 invoked from network); 4 Aug 2001 04:53:12 -0000 From: Sven Wischnowsky Date: Fri, 3 Aug 2001 10:25:37 +0200 (MET DST) Message-Id: <200108030825.KAA02280@beta.informatik.hu-berlin.de> To: zsh-workers@sunsite.dk Subject: Re: _chflags In-Reply-To: <3B697DA9.3443713E@yahoo.co.uk> 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@informatik.hu-berlin.de