Re: PATCH: Re: "Cancel" menu selection & Co?

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Andrej Borsenkow wrote:

> ...
> 
> Oh, yes, and you did not comment on per-completion widget styles. Is it
> possible? Does it make sense (that is, are there any settings that may be
> usefully set differently for different completion widgets)? The only
> thing I had in mind was listing - but you did it with this patch.

Sorry, forgot that. Currently we don't support it, which becomes
obvious by looking at the context names which don't include the widget 
name or class.


Aside: I've been playing with a little completer named `_guard' that
works a bit like _prefix and _ignored, i.e. it looks up completers
and calls them -- based on some condition. E.g. you could say:

  zstyle '...' guarded-completer \
    '[[ $WIDGET = *list* ]]' _complete:-list - \
    ... # other conditions/completers here

With this, listing widgets would use _complete, but under the name
`complete-list' and you could set the styles for them.

I then decided that I don't like this approach. Then I thought again
about adding conditionals to styles. For testing purposes, this could
be implemented by a new completion widget that calls _main_complete,
but defines a `zstyle' function before that. This functions could then 
do the real style-lookup and interpret the value, so that, for
example, one could use:

  zstyle ':completion:*' completer \
    if '[[ $WIDGET = *list* ]]' \
      _complete \
    else \
      _complete _approximate \

I.e. `if', `elif' and `else' are keywords. The first string after `if' 
and `elif' is eval'ed and if it return zero, the strings after it up
to the next `elif', `else' or end-of-value is the value returned for
the style (if there are no words, the style is unset under this
condition). The `if' as the first word also makes this distinguishable 
from unconditional values.

Something like this would allow us to finally get rid of the rather
ugly styles that contain conditions, like the ones used by
_expand. One could write:

  zstyle ':completion:*' substitute \
    if '[[ ${{NUMERIC:-1} -ne 1 ]]' yes else no

I haven't played with an implementation of this because it reminds me
too much of the `invent a little language'-trap. Using shell syntax
here could mean that the wrapper makes every style value be eval'ed as 
a whole and uses the `reply' array:

  zstyle ':completion:*' completer \
    'if [[ $WIDGET = *list* ]]; then
       reply=(_complete)
     else
       reply=(_complete _approximate)
     fi'
Although `value=(...)' would probably be better. And we should have a
way to tell the wrapper if the value is to be eval'ed or not, for
example with a special first value like `eval:' or some such.

Having to make the wrapper define a function for this is ugly. If
heavily used, this should be done in C. 


Note: I don't plan to implement this right now, or, more exactly, I
don't plan to try to convince anyone that we should do this or to get
a patch for it into the distribution. Maybe I'm just crazy.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx