RE: PATCH: completion parameters etc.

["Andrej Borsenkow" <borsenkow.msk@xxxxxx>]

> -----Original Message-----
> From: Sven Wischnowsky [mailto:wischnow@xxxxxxxxxxxxxxxxxxxxxxx]
> Sent: Monday, March 01, 1999 3:10 PM
> To: zsh-workers@xxxxxxxxxxxxxx
> Subject: PATCH: completion parameters etc.
>
>     - `list': May be `list', `autolist', `ambiguous' or unset. Can be
>       used to control the completion listing behavior by setting it to
>       one of these values.
>     - `insert': May be `unambiguous' (for non-menucompletion), `menu',
>       `automenu' or unset (for listing-only). May be set to control if
>       and how the command line should be changed.
>     - `exact': Set to `accept' or unset by the completion code. May
>       also be set to `accept' or unset. This controls if `REC_EXACT'
>       should be used. Only too late I thought about adding a key
>       `exact_string' that can contain the string itself. I may produce
>       a patch for this later.


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?

regards

/andrej