From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1449 invoked from network); 6 Aug 2001 11:36:58 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Aug 2001 11:36:58 -0000 Received: (qmail 4539 invoked by alias); 6 Aug 2001 11:36:49 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15571 Received: (qmail 4527 invoked from network); 6 Aug 2001 11:36:48 -0000 Sender: kiddleo Message-ID: <3B6E8147.58B021E1@u.genie.co.uk> Date: Mon, 06 Aug 2001 12:36:39 +0100 From: Oliver Kiddle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: zsh-workers@sunsite.dk Subject: grouping inverses and sorting in completion lists (was _chflags) References: <200108030825.KAA02280@beta.informatik.hu-berlin.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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