From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3501 invoked from network); 13 Apr 2000 09:01:03 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Apr 2000 09:01:03 -0000 Received: (qmail 26365 invoked by alias); 13 Apr 2000 09:00:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10730 Received: (qmail 26341 invoked from network); 13 Apr 2000 09:00:45 -0000 Date: Thu, 13 Apr 2000 11:00:26 +0200 (MET DST) Message-Id: <200004130900.LAA13677@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Thu, 13 Apr 2000 10:35:18 +0400 Subject: Re: Default tags in _arguments and some more ... Andrej Borsenkow wrote: > For file arguments - is it possible to specify default set of patterns > that can be overridden using styles? More general - is there easy way to > assign a tag inside _arguments description? What I mean, is something > like > > -I::compressed files:*.gz\:"compressed-files\:compressed-files" > > with the effect, that tag name ``compressed-files'' with default pattern > *.gz is used when completing argument of -I option. This from the man who wanted a single tag for all files to specify styles to be used whenever files are completed? Currently _files can't be given pattern/tag/description arguments, it's all (and only) under user control. I admit I though about it, but wasn't sure if it's worth it (implementation wouldn't be too hard). The syntax would be something like `_files -p "*.gz:...:..."', though. I didn't do it mainly because I wanted to keep the number of tags used for files small. > More general, > something like > > -F[file system type]::file system type:fsys-type(ufs vxfs) > > that would use tag ``fsys-type'' when completing arguments of -F option. Tags are really only specified by the final completion function. So, _arguments could do it for the `(...)' actions, but otherwise... Hm. I can see the sense in doing it for `(...)', but the syntax would have to be something like `(...):tag'. But when the action is, e.g., one of our utility functions it would use the tags it always uses, so the result might be a bit irritating, I think. > As I understand, currently the latter is impossible (_inline_ - of > course, using states everything is possible), and the former is limited > to calling _files with patterns that will assign all patterns to > globbed-files. > > There are a couple more issues I do not much like > > - special usage of blanks; it is way too easy to accidentally miss ot > misplace them > - very strict syntax for values. It is hard to add something new (as we > have seen recently) and every new addition may be incompatible. [ you mean actions ] > So, here is suggestion that may be useful: > > use flags to define semantic values. Something like > > ...:::[l]foo bar baz - for literal list of values > ...:::[e]a shell string - for eval'ed string > etc > > This has a major advantage of being extensible without breaking existing > usage. And we can easily define new flags like > > ...:::[p]*.gz *.Z - for file patterns; or even > ...:::[p]*.gz:gzip-file *.Z:compressed-files - using the same syntax as > for styles; Argh. No special casing for files, please. If we start with that the next thing would be a flag for parameters, one for command names, one for... in other words: compctl. > ...:::[t/weird-tag/]... - use tag `weird-tag' when completing these > values Well, some of this might be easy, but we would probably need help from C-code when the flag lists get more and more powerful. But thinking about changing/checking every function that uses _arguments, _values or _alternative gives me the creeps. So, feel free to write that... ;-) (I agree it looks nicer.) Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de