Re: _files vs _path_files discussion (old thread)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx