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

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

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

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

Now consider the set of tests that completion applies to decide upon an
action from the above list:

* Is the current word in "command position"?
* Is the current word a builtin command?
* Is the current word an external command?
* Is the current word a file name?
* Ditto, but matching a particular glob pattern?
* Is the current word a directory name?
* Etc., etc.

Presently, if a user wants to perform those tests, the only recourse is
to use a compctl -K function, use `read -nc nword;read -Ac args`, and
then write all the tests by hand.  And he has to specify in the compctl
(or in options for menucompletion), outside of that function, what the
resulting input line behavior is.

An example is multicomp -- it'd be nice to be able to say, "if this
completion is a directory name, then append a removable slash, else
append a space."

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.

This is similar to what Peter did in his completion widgets patch, but
exposes even more of the mechanism.

It's sort of a RISC v. CISC argument, actually; it's easier to understand
what's going on with RISC instructions, because each one is simpler, but
you have to issue a lot more of them to get anything done.  The current
compctl is confusing for two reasons:  (1) it uses single-character and
thereby minimally mnemonic options to describe everything; and (2) the
effect of any one of those options may be a very complex change to the
input, and so combining them is either bewildering or impossible.

Addressing (1) with a flowery syntax doesn't help with (2), and I think
that if (2) were cleaned up then the syntax for (1) wouldn't need to be
as flowery.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com