Re: Completing parameter names that have yet to be set.

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Felix Rosencrantz wrote:

> I was unaware of the "fake" style.  I just looked at _parameter before
> posting. It seems that "fake" covers the functionality I was thinking
> about for files.  It seems that _parameters also needs the ability to
> fake values as my copy does.  There probably are other places where fake
> could be used.

As I said, that's why I used a generic name (I haven't thought of
other places where it may be useful yet, though).

> ...
> 
> It seems whatever format is used for "fake-parameters", it should allow
> the user to specify descriptions.  Also type information would be nice.

That may be another difference, I think. I.e., I'm not sure if the
descriptions are useful everywhere. In the case of the fake-style-for-
files, listing them separately may get a bit complicated (control-flow-
wise in _path_files).

Question to everyone: should we change `fake' to `fake-files' now?
And how important do you consider allowing users to give a (optional)
description for them? (I.e.: for the faked *files*.)

> One thing I really like about the fake style used for files is that
> it provides a mechanism for context based on the directory of the
> completion.  I've wondered if there is a way to generalize this so that
> other styles could be based on the directory of completion (or other
> information).
> 
> The completion system has so many styles that allow the user to tweak
> completion.  All these different styles provide hooks to the various
> tools of the completion.  Different situations require different tools.

Note the word `tools'. Isn't that synonym for `commands' here?

Anyway, one can always program that with `zstyle -e', I think.

(But yes, in this case at least, the directory where we complete in is 
indeed context information. I don't have the slightest idea where we
could make that information available for easy matching, though. I
mean, a completion-context with a pathname in it looks weird. And to
allow to specify the glob patterns based in it we would have to test
it in _files, and _path_files (if it was called directly). Hm.)

> ...
> 
> It seems that the ability to configure styles based on additional
> information not found in the context requires the ability to treat a
> group of styles as a single whole, and quickly set/unset a group of
> styles.  I vaguely remember something like this was talked about, but
> don't remember what was decided.

I only said several times that I would wish I had an idea how to do
that ;-)

This kind of feeling comes from the times when I wished we had easy
ways to support multiple sets of <insert-your-favorite-feature>,
e.g. histories, key bindings, etc.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx