Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> ...
> 
> } What we currently know as key functions that do completion would be
> } implemented as widgets. The completion functions we have now are
> } builtin widgets but others can be defined by the user.
> 
> Sort of, but not widgets in the sense of existing zle widgets (that is,
> I don't want to have to choose just one of them to bind to the TAB key).
> When you say:
> 

What I meant was: all the mechanisms needed to reimplement each of the 
currently existing completion key functions would be available to the
user, for compatibility we would preserve them as builtin key
functions.
Of course, since everything need to rimplement them should be broken
in several parts, users would be able to define completion functions
with behaviors different from all currently known completion
functions.

> } Such a widget for completion would select a shell function that
> } produces the matches. I.e., no more compctls but shell functions that
> } use the builtin to produce matches and that use `if...then' and other
> } things for things we now do with `-x' (which will become obsolete).
> 
> I wasn't thinking of quite so much differentiation between the "widget
> for completion" and the "function that produces the matches"; that is,
> there's no reason the widget couldn't produce the matches directly,
> and no reason the function that produces the matches couldn't also e.g.
> set the autoremovable suffix or specify that menu completion be used.
> 

Of course. The shell functions called to produce the matches would
just be shell functions in the same special `calling environment' as
the widget. So this widget itself would be able to produce matches and 
the functions called would be able to say something about how matches
should be inserted, presented to the user, or whatever.
If we use something like `completion contexts', these could be
modified even outside any of these functions.

(There would be a bit of a problem with the allocation behavior of the 
completion code, since we would need these context and the matches in
them be allocated in real memory where the completion code now uses
heap memory.)

> (It'd also be great if every match in the list could have some of its
> own attributes, e.g. prefix and suffix strings, -U-ness, etc.  But I
> think that can wait for the next overhaul.)
> 

My patch for inclusive-ors already does this for many of the different 
things for which it would be useful (-P, -S, -U, and for -Q it was
always done).

> 
> } After all selected completion-producing shell functions have been
> } executed, the widget uses the builtin to say what should be presented
> } to the user (e.g. show a list of matches, change the command line, or
> } both, or...).
> 
> Possibly.  I was hoping all that could be set up in advance, i.e. during
> generation of the matches, and then applied when the entire match list
> was finally available.  (Maybe that would require per-match attributes,
> which I just wrote off for now.  Hm.)
> 

As I wrote, here I was thinking only about things like `should we
show a list?', not about things like `how should this match be
inserted?', that can (and should) be defined when the matches are
generated.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx