From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7954 invoked from network); 18 Jan 2002 18:24:40 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 18 Jan 2002 18:24:40 -0000 Received: (qmail 15875 invoked by alias); 18 Jan 2002 18:24:33 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16466 Received: (qmail 15864 invoked from network); 18 Jan 2002 18:24:33 -0000 X-VirusChecked: Checked X-Authentication-Warning: iris.logica.co.uk: Host rambo.logica.co.uk [158.234.33.58] claimed to be yahoo.co.uk Sender: kiddleo@iris.logica.co.uk Message-ID: <3C486844.F6D715AA@yahoo.co.uk> Date: Fri, 18 Jan 2002 18:24:04 +0000 From: Oliver Kiddle X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.16-686-smp i686) X-Accept-Language: en MIME-Version: 1.0 To: zsh-workers@sunsite.dk Subject: Re PATCH _file_systems & Re zstyle for _arguments feature request Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sven wrote: > With this, I agreee with Oliver that this might indeed be the real > problem, so I changed the implementation of `compadd -x'. Messages > added with that still always show up, but otherwise they are now like > the descriptions added with -X. Then I changed _message to accept the > option `-e ' which adds such a description for the given > tag. This looks good and seems to work well. I've also not found any problems with the patches for the fake style and for function arguments in compdef. On the subject of the fake style, if we find that there is demand for something more powerful, using _alternative like specs would probably be sufficient though I'm not sure whether that could be made to work because the functions need to be called from somewhere. Using zstyle -e with the current fake style allows some fairly powerful things to be done but there can be problems.. While I'm on the subject of recent patches, the man page sectioning patch is great so thanks for that Sven. I only wonder that the separate-sections style shouldn't be the default. For people who don't like it, the group-name style can re-group them but is there any way to have one description for the re-grouped sections. > We would have to look through the functions using > _message to see which of them should be changed to use `_message -e'. Yes. I could do that if you don't want to but it would have to then wait as I'm about to leave for a week of skiing in Austria. > I've done this for _chown as an example (to show you how simple it Note that the tag in this _chown change should be `options' instead of `option'. I have found one small thing which I don't think is right though: zstyle ':completion::complete:grep:argument-1:*' fake one two three grep x Because x doesn't match one two or three, it is now not displaying the message `pattern' but it isn't saying `No matches for ' either. Continuing to display `pattern' would perhaps be best because matches added with fake are probably not an exhaustive set. There are completion functions where we don't add an exhaustive set of matches either. An example would be after vncserver -geometry (any x y combination would be valid). Perhaps in these cases, by using -x instead of -X, the message should persist instead of getting `No matches for...'. It would also be very useful in cases such as this in _cvs: if (( $#vendor_branch )); then _wanted values expl 'vendor branch' compadd -a vendor_branch else _message 'vendor branch' fi _wanted would need to be modified to take the -x option which would cause it (or _description) to change -X in expl to -x. _cvs would then only need to do: _wanted -x values expl 'vendor branch' compadd -a vendor_branch > would be), but there are other places. The utility and core functions > should be ok with this patch, except for _guard, where I'm not sure. > Maybe we have to give it an option to tell it if the description is > supposed to be a only message or such a new description-without-matches > thing. Looking at where we've used _guard, it certainly needs to be able to use the description-without-matches thing but whether _guard might ever be used for a plain message, I'm not sure. I can't see why it ever would. We could always add an option for that later if it is needed. Oliver ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________