Re: _files vs _path_files discussion (old thread)

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mar 13,  2:07pm, Sven Wischnowsky wrote:
} Subject: Re: _files vs _path_files discussion (old thread)
}
} Bart Schaefer wrote:
} > 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?

I don't, actually ... so probably there isn't any.

} > One possibility would be to make file-patterns itself into a hierarchy;
} 
} 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').

It should mean the files selected by the caller.
 
} Much more dramatic second question: should we get rid of globbed-files,
} directories, all-files?

The problem with getting rid of them is that e.g. _cvs uses 'directories'
to mean something different than '*(-/)' (in effect, to omit the CVS/
subdir and any subdir that doesn't contain a CVS/ subdir).  It's useful
to be able to define "directories" independently of other glob tags.

(Of course, _cvs and its helpers don't test the file-patterns or call
_files, they use compadd directly.  So it's not quite the same issue,
but it could still come up.)
 
} 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.

Perhaps.

}   file-patterns == 'globbed-files:*.ps' 'directories:*(-/)' ...
} 
} or something like that.

That might cover it, though I dislike putting the tag name in the same
word as the pattern.  We already have too many strings that have to be
split into substrings before interpreting, as far as I'm concerned.

} [...] And then [_files] 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?).

I don't understand the question, I fear.

} Changing _files this way would make it much easier (and better
} readable and hence easier to modify), obviously.

I'm all in favor of that ...

} 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?

I don't think users fiddling with glob patterns is a problem; it's not
much by comparison with figuring out style context names in the first
place.  I'm more concerned about what the completion functions do in
cases like the _cvs example I mentioned above.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com