From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21089 invoked from network); 13 Mar 2000 13:07:20 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Mar 2000 13:07:20 -0000 Received: (qmail 16622 invoked by alias); 13 Mar 2000 13:07:08 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10114 Received: (qmail 16610 invoked from network); 13 Mar 2000 13:07:07 -0000 Date: Mon, 13 Mar 2000 14:07:05 +0100 (MET) Message-Id: <200003131307.OAA19863@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Sun, 12 Mar 2000 00:18:53 +0000 Subject: Re: _files vs _path_files discussion (old thread) Bart Schaefer wrote: > ... > > zstyle ':completion::complete:tar::' \ > tag-order 'globbed-files directories all-files' I was about to write that this doesn't make much sense, because all-files would generate all files, so the first two tags aren't really needed. I wanted to add that it doesn't matter though, because _files takes care to call _path_files only once in sucha a case. Then I remembered file-patterns... uh oh. This `call _path_files as seldom as possible optimisation' in _files is wrong now that we have file-patterns, so I have to hack it anyway... [ skipping several messages... ] > On Mar 12, 6:21am, Bart Schaefer wrote: > } Subject: Re: _files vs _path_files discussion (old thread) > } > } [*] Sven's suggested change was: > } } ... should we make the directories tag with its usual pattern be > } } tried automatically if the user explicitly sets the file-patterns tag > } } for globbed-files? Or should we do that only if the directories tag, > } } file-patterns style is given, but allow an empty value to stand for > } } `the normal pattern'? > } > } My short answer is that I don't think there's any good solution. The > } tag-order style is going to be confusing no matter what we do [...] > > One additional thought: It would be nice to be able to specify that > _paths_ are completed, rather than merely directories; i.e. like the > difference between "compctl -g '*(-/)'" and "compctl -/". I'm not > convinced that "zstyle *directories file-patterns '*(-/)'" does that. Actually, I thought that _path_files makes it behave like `compctl -/', where do you see a difference? Oh, and `*(-/)' is the pattern used by _path_files if given the -/ option. > } some kind of blaring all-caps text in the tag-order documentation: > } > } NAMING A TAG IN TAG-ORDER DOES NOT CAUSE COMPLETIONS FOR THAT TAG TO BE > } GENERATED; RATHER, IT SORTS THE COMPLETIONS AFTER THEY ARE GENERATED. > > Hrm, maybe even add "... BUT ONLY _IF_ ANY ARE GENERATED FOR THAT TAG." Yep. [ skipping even more messages... ] > Effectively, what you want is to subdivide the 'directories' tag and > have it treated like it has it's own internal tag-order. There isn't > any way I can think of to express that at the moment. > > One possibility would be to make file-patterns itself into a hierarchy; > that is > > zstyle :completion::complete:tar::directories \ > file-patterns '*(-/)' '.*(-/)' > > would mean to use '.*(-/)' only if '*(-/)' returned nothing. The current > meaning of the above is also expressible by > > zstyle :completion::complete:tar::directories \ > file-patterns '*(-/) .*(-/)' > > (that is, file-patterns is presently a string, not an array) so we would > not be losing any functionality. Nice idea. And doesn't sound too hard to implement... > Then all we need is a magic token in file-patterns to mean "use anything > passed to _files with the -g option here" and global file-patterns would > become really useful. Maybe we could just use an empty string as the magic token, it's used elsewhere already. First question: should the magic token only be used for -g or also for -/ (i.e. should it mean: `the glob-pattern from the caller' or `the files selected by the caller'). Much more dramatic second question: should we get rid of globbed-files, directories, all-files? I mean: if we change the file-patterns style as suggested, then a call to _files with, say, -g '*.ps' has the same effect as using file-patterns == '*.ps' '*(-/)' '*' Allowing multiple patterns in file-patterns and still using multiple tags doesn't add much to functionality, but adds a lot to obscurity, I think. The only thing missing is that there aren't different tags used, which could otherwise be used by style patterns. But 1) sometimes these different tags are a bit in the way, e.g. when setting ignored-patterns and 2) it would be easy to enhance the syntax for file-patterns to include (dreamed up) names of tags. file-patterns == 'globbed-files:*.ps' 'directories:*(-/)' ... or something like that. Hm... _files would take its arguments to get a set of patterns to try. Then it looks at the file-patterns style, using the `files' tag. If that is set, only those patterns are used, unless there is the magic token which means `insert the special supplied pattern here, if there is any'. And then it calls _path_files for the patterns until one generates matches. Either always using the files tag or the tags given in the file-patterns value (if we implement that; should the standard patterns automatically derived from the arguments of _files use the tags we use now, then?). Changing _files this way would make it much easier (and better readable and hence easier to modify), obviously. But it would mean that users would have to fiddle with glob patterns instead of only tags in this case -- I'm never sure, what is considered too inconvenient: is this onme of those cases? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de