Re: icomplete.el enhancement

[Stefan Monnier]

> * When several completions are possible, the common completion stem (prefix)
> is distinguished from the different completion remainders (suffixes).
> The two are shown in different faces, which are user-definable (variables).
> Without this enhancement, incremental completion can be quite confusing
> (*not even worth it*), IMO.

I don't understand.  icomplete shows the common completion prefix (i.e. the
string that would be inserted should the user hit TAB) between parentheses
already.
Do you mean that your code just highlights this part in a different color
(additionally to the use of parentheses)?  Or does it do something different?

> * The completion alternatives are sorted (using string<).

I think icomplete deserves indeed some improvement in this area.  It should
also allow "cycling" and selection of the first element, as done in iswitchb.

> * Icompletion is not done if the minibuffer input begins with `(', since the
> input is not a command name (it is probably an Emacs Lisp expression to be
> submitted for evaluation).

I don't understand: icomplete-mode is not activated if there is no
minibuffer-completion-table, so it's not activated in M-: and such.  If you
see it activated when it shouldn't be, you should report it as a bug, but
using `(' as a hint is most likely not the right way to fix it.

> * Out of the box, icompletion interferes with the
> `minibuffer-completion-table' (or vice versa). To fix this, the following
> Emacs primitives have been redefined so that they avoid icompletion:
>   . read-from-minibuffer
>   . read-no-blanks-input
>   . read-string

Huh?  icomplete is already never enabled in such cases, AFAIK.


        Stefan