RE: PATCH: completion parameters etc.

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Andrej Borsenkow wrote:

> Aha! I had slightly different idea, but yourth is probably more general
> anyway ... But for the record ...
> 
> Currently (not as current already :-) we have several ad hoc builtin
> completion widgets and use them to describe behaviour of user-defined ones.
> My suggestion was actually to define a set of per-widget parameters that
> describe how completion behaves and use zle command to set them.
> 
> I call them parameters and not flags because I expect some of them to take
> arguments. The problem is to find out the proper set of orthogonal features.
> At least list, menu, expand, complete seem to be quite independent. In this
> way one could define a widget, that would e.g. list possible expansion (yep,
> we already have such a beast). And with menu parameter we could say, at
> which attempt should menu start. Zero (disable), one (zsh traditional), two
> (bash).
> 
> But here the question: how do your state parameters interact with global
> options? Such as automenu etc?

With the new compstate-keys we could almost avoid having to give the
name of a builtin completion widget to `zle -C' (since users can
re-implement anything). But I'd be against this, because (and this is
the answer to your question) I think it is very convenient to have a
simple way to set the initial values for the keys in a way that make
things behave like the widgets one is used to (if they are left
untouched by the widget). I.e. currently the `emulated' builtin widget
and the option settings are used to set the values when the completion
widget is called. After the widget exits, the code uses the current
values, so if the widget changed them, the behavior will differ. Of
course, options will not be altered by the code.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx