Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

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

Bart Schaefer wrote:

> ...
> I suggest that we provide a builtin (or a collection of them) to apply
> the collection of tests to the current input line, plus a collection of
> what amount to zle widgets to permit the user to explicitly direct the
> changes to the input line that take place when the tests succeed.

Ok, I'll try to collect the suggestions you made, combine with a few
additions from me, and come up with a description for that.

We have a new builtin that allows us to use (parts of) the completion
code. The builtin allows us to create, change, and destroy completion
contexts. Changing them means to add matches, to remove matches, or to 
change matches.

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.

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).
The builtin may offer some support for selecting a shell function
appropriate for the current command line (of course, this wouldn't
depend on the command line itself, but would somehow allow us to
quickly select a (few) function(s) for certain command names or

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

Using compltion contexts makes it possible to implement menu
completion easily (there might be an option to the builtin that says:
use the next match from context ...). It would also allow us to define 
widgets that do menu-completion while allowing other editing commands
between menu-completion commands. Of course, lots of other interesting 
things should be possible with that, too.

Hm, I think all this sounds good, and even not too hard to implement
(my last changes to zle_tricky.c might even help with this since they
make the completion code in question cleaner).

Some questions are:

- Are shell functions much bigger?
- Would this be too slow?
- Are there any problems I didn't see right now?

Anyway, did I understand you correctly (enough)? And what do the
others think about all this?


Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx

Messages sorted by: Reverse Date, Date, Thread, Author