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

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

[Sven Wischnowsky]

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@informatik.hu-berlin.de

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

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> ...
> 
> So I took a quick look at Src/Modules/zutil.c which implements zstyle.  It
> looks like all the styles are held in a list pointed to by the static global
> "zstyles".
> 
> It seems like it wouldn't be too hard to be able to maintain multiple lists
> that the value of zstyles could then be pointed to.  The multiple lists could
> be stored as the values in a hash table, the keys would be the names of these
> lists.
> 
> There would need to be user command(s) to set the name of the current list, get
> the names of the lists, set the name of the current list.  To edit a zstyle
> list, you need to make that the current list pointed to by zstyles.
> 
> Seems like something like that would allow having multiple configuration sets,
> and being able to quickly change them.  And wouldn't require too many changes
> to the existing source code.
> 
> How does that seem?  Useful? Easy to implement or are there a lot of issues I
> missed?

Well, for styles we'd probably need something smarter: sub-groups. Because 
people would want to temporarily replace/change/override only some
styles, not the whole set, so that some of the more basic styles are
always available. I think.

> Also, I while looking at zutil.c, I noticed that the function evalstyle() only
> modifies the existence of the parameter reply.  Would it be useful to provide
> a parameter that said what the current context is?  It seems it might
> make it possible to write some generic functions that could be given
> to a "zstyle -e" and make some decisions based on the context.  The current
> context can be different from the context supplied to the zstyle command.  The
> context provided to the zstyle command could be a pattern.

That sounds sensible.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

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

[Felix Rosencrantz]

Way back in August in workers/12608,  Sven Wischnowsky wrote:

>> ...
>> 
>> 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.


So I took a quick look at Src/Modules/zutil.c which implements zstyle.  It
looks like all the styles are held in a list pointed to by the static global
"zstyles".

It seems like it wouldn't be too hard to be able to maintain multiple lists
that the value of zstyles could then be pointed to.  The multiple lists could
be stored as the values in a hash table, the keys would be the names of these
lists.

There would need to be user command(s) to set the name of the current list, get
the names of the lists, set the name of the current list.  To edit a zstyle
list, you need to make that the current list pointed to by zstyles.

Seems like something like that would allow having multiple configuration sets,
and being able to quickly change them.  And wouldn't require too many changes
to the existing source code.

How does that seem?  Useful? Easy to implement or are there a lot of issues I
missed?

Also, I while looking at zutil.c, I noticed that the function evalstyle() only
modifies the existence of the parameter reply.  Would it be useful to provide
a parameter that said what the current context is?  It seems it might
make it possible to write some generic functions that could be given
to a "zstyle -e" and make some decisions based on the context.  The current
context can be different from the context supplied to the zstyle command.  The
context provided to the zstyle command could be a pattern.

Maybe I need to get some rest... :)

-FR


__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

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

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Aug 13, 10:51pm, Felix Rosencrantz wrote:
> } Subject: Re: Completing parameter names that have yet to be set.
> }
> } For example, in my source code tree I might want to look at ".[ch]"
> } files first, but in logs directory I want to look ".{log,out}" files
> } first.  I can use tags, but I still have to list tags for ".[ch]" and
> } for the ".{logs,out}" files. And if both types of directories contain
> } files that match both tags, there will be at least one directory where I
> } always get the incorrect completion the first time.
> }
> } [...]
> }
> } 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.
> 
> This is what both `zstyle -e' and the `func()' value for the tag-order
> style are supposed to accomplish, I think.

Yes.

> In fact, given `zstyle -e',
> we could probably do away with `tag-order func()'.

I've been thinking the same. Hm, should we?

> ...
> 
> Or something like that, I didn't try it so I've probably got it cockeyed.
> And of course you'd have to come up with a more sophisticated test for
> $PREFIX or whatever, to tell what kind of directory is what.

For directories this is a bit of a special case, because of possible
-W options.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

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

[Bart Schaefer]

On Aug 13, 10:51pm, Felix Rosencrantz wrote:
} Subject: Re: Completing parameter names that have yet to be set.
}
} For example, in my source code tree I might want to look at ".[ch]"
} files first, but in logs directory I want to look ".{log,out}" files
} first.  I can use tags, but I still have to list tags for ".[ch]" and
} for the ".{logs,out}" files. And if both types of directories contain
} files that match both tags, there will be at least one directory where I
} always get the incorrect completion the first time.
}
} [...]
}
} 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.

This is what both `zstyle -e' and the `func()' value for the tag-order
style are supposed to accomplish, I think.  In fact, given `zstyle -e',
we could probably do away with `tag-order func()'.

zstyle ':completion:*' file-patterns \
	'*.[ch]:c-sources' '*.(log|out):log-files' '%p:all-files'
zstyle -e ':completion::complete:*' tag-order \
	'if [[ -d $PREFIX/CVS ]]; then reply=(c-sources all-files);
	 else if [[ $PREFIX == */log ]]; then reply=(log-files all-files);
	 fi'

Or something like that, I didn't try it so I've probably got it cockeyed.
And of course you'd have to come up with a more sophisticated test for
$PREFIX or whatever, to tell what kind of directory is what.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

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

[Felix Rosencrantz]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2452 bytes --]

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.

It does seem that if the format is different, the style name should be
different.  Though I do like the idea of the "fake-" prefix, being used
with the styles names that provide additional values to the values found
via the normal mechanism.  So maybe a "fake-parameters" style to allow
for parameters that haven't been set.

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


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.

For example, in my source code tree I might want to look at ".[ch]"
files first, but in logs directory I want to look ".{log,out}" files
first.  I can use tags, but I still have to list tags for ".[ch]" and
for the ".{logs,out}" files. And if both types of directories contain
files that match both tags, there will be at least one directory where I
always get the incorrect completion the first time.

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.

This sort of seems similar to the keymaps. We want to quickly set a
group of keymaps at once. The ability to place a bunch of key mappings
in the name space of a keymap, seems like what we want to do with
styles.  Place a bunch of them in a name space, and then provide a list
of name spaces to search like a path.

-FR.


__________________________________________________
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

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

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> Since there is some talk about parameter completion...  I've had a
> custom version of _parameter for some time that I've been meaning to
> document and submit.  The customization was that it could complete
> parameters that were not yet set.  Using a style, the user specifies a
> list of parameters that they want zsh to know about to complete.
> 
> For example, with the zsh distribution there is the TESTNUM environment
> variable, which can be used to specify a subset of the zsh tests when
> running "make check" . However, most of the time this environment
> variable is unset.  I can't always remember the special variable.  So
> it's nice that zsh completion can.

That's why I gave the `fake' style such a generic name. Although that
probably wasn't so clever, because the value-formats may have to
differ for different types of completions to fake.

> I think it would be useful if the style specification allowed for descriptions
> of these parameters.  The descriptions could be used for parameters that
> are already set.  Though I'm not sure how to do this (with _values?).

`fake' doesn't allow this yet (and the way it is used makes it hard
(and probably a bit ugly, code-wise) to implement it there). But of
course one can always do it with tag-labels and ignored-patterns.

> ...
> 
> It seems like the ability to tell zsh of words that can't be found by
> querying the system (e.g. these parameter names, files that don't exist
> yet, etc. ) would be useful.  I was thinking that it would be useful
> to add some generic code that would (maybe a completer). Maybe using
> the new cache system. The code would allow the user to specify a set of
> words to be tossed in with the words that standard completion functions
> complete.  I'm not sure what would be a good solution.  This is more
> meant to provoke some response/thought by the completion gurus.  

Given that the faked completions depend on the contexts, the type of
completions and the user's preferences, I don't know how a function
could help here. Maybe we'll just have to use `fake' (or several
`fake-this-or-that' styles that replace `fake'), get some experience
with it and then find out if and how we can improve it. And if it's
needed.



--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Completing parameter names that have yet to be set.

[Felix Rosencrantz]

Since there is some talk about parameter completion...  I've had a
custom version of _parameter for some time that I've been meaning to
document and submit.  The customization was that it could complete
parameters that were not yet set.  Using a style, the user specifies a
list of parameters that they want zsh to know about to complete.

For example, with the zsh distribution there is the TESTNUM environment
variable, which can be used to specify a subset of the zsh tests when
running "make check" . However, most of the time this environment
variable is unset.  I can't always remember the special variable.  So
it's nice that zsh completion can.

I think it would be useful if the style specification allowed for descriptions
of these parameters.  The descriptions could be used for parameters that
are already set.  Though I'm not sure how to do this (with _values?).

I've included a copy of what I've got so far.  No docs, and currently
out-of-date with respect to Oliver's changes.  And not fully tested.  It
works for me, though.  I wasn't sure if _alternative could be used here.
Also, it doesn't allow for descriptions of the parameters.  Also, to be
even more complete I guess type information could be provided to be used
in conjunction with the -g flag Oliver just added.  Anyone is welcome to
take this code or idea and add it in.  I haven't done much with it in a
while.

It seems like the ability to tell zsh of words that can't be found by
querying the system (e.g. these parameter names, files that don't exist
yet, etc. ) would be useful.  I was thinking that it would be useful
to add some generic code that would (maybe a completer). Maybe using
the new cache system. The code would allow the user to specify a set of
words to be tossed in with the words that standard completion functions
complete.  I'm not sure what would be a good solution.  This is more
meant to provoke some response/thought by the completion gurus.  

-FR.

#autoload

# This should be used to complete parameter names if you need some of the
# extra options of compadd. It completes only non-local parameters.

local expl extraparams unsetparams p existparams

zstyle -a ":completion:${curcontext}:" parameter-list extraparams

unsetparms=()
for p in $extraparams ; do 
        if [[ $+parameters[$p] -ne 1 ]] ; then
                unsetparams=($unsetparams $p)
        fi
done

existparams=(${(qk)parameters[(R)^*local*]})
_alternative \
        "parameters:parameters already set:{compadd ${(q)@} - $existparams }" \
        "unset-parameters:parameters not already set:{compadd ${(q)@} -
$unsetparams}"


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/