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

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Bart Schaefer wrote:

> 
> Let's think about this a different way for a moment.
> 

Yes, I thought about similar things since your last mail...

> First, consider the manipulations that completion performs on the input
> line:
> 
> * Insert a word fragment at the cursor.
> * Erase the whole current word and replace it with another one.
> * Either of the above, but cycling through a list of replacements.
> * Append a suffix to the word or word fragment.
> * Set a flag indicating that the suffix is a candidate for removal.
> * Move the cursor to the end of the word.
> * Insert a space if the completion appears unique.
> * Etc. (I'm sure I've missed some.)
> 

I prefer thinking about collecting information, like:

- what should be shown in the case of ambiguous information
  (here and in menu-completion, which is the same as the behaviour for 
  a single match I nowadays only think of: `remove the current word,
  replace it with ...', makes things easier)
- which part of the inserted line should be automatically be removed
  (after which keys are typed)
- for each match: what should be inserted
- for each match: what should be listed
- for each match: is it a file? (if it is a file, we probably need a
  path for file type testing with LIST_TYPES)
- the things from the options (like recexact, automenu,
  listambiguous,...)

What should be inserted depends on things like:

- a -P prefix
- a -S suffix
- probably some ignored prefix that already was on the line
  (this also determines where the -P prefix should be inserted)
- some extra slash, space, etc.
- two strings that were temporarily removed if we are completing
  inside a brace expansion
- quoting or not

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

You mean that we should use a function for each case where we now use
a compctl (or probably you mean to use one fornction for all compctls
together), right?
I would prefer the solution with different functions which would
probably be called from some `master function (or widget)'. We could
add some support to make the selection of the function(s) easier.
The sub-functions would then call the builtin(s) to generate the
matches, they could access the command line (making compctl -x
superfluous, use `if ...' instead). They would probably also make
suggestions how to present things to the user (which could be
overridden in the master function).
The information collected could be stored (like the matches are stored 
now for later menu-completion) and made accessible via some builtin,
more precisely: all the `add matches for some kind of test' things
would only add to this information. We could add ways to create new
such collections, remove some things from them, add to them, change
them, and remove them. This would allow for things like: do
completion, do something other, continue completion at the place were
we just left.
For this `master function' we should add some builtin implementations
that use the well known options, compctl would be removed/changed.

Ok, I just tried to collect your ideas from various mails, did I
interpret them correctly?

I like this approach and it doesn't even look too hard to implement
(if we do it in multiple steps, the information gathering phase can
become quite tricky (internally)), my last patches may even help here
since they cleaned up some parts of zle_tricky.c.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de