RE: icomplete.el enhancement

["Drew Adams" <drew.adams@oracle.com>]

Sorry for the confusion.

I guess several of my fixes were to *old* emacs code that has since been
cleaned up. I've looked again at the icomplete.el code for Emacs 20, and it
doesn't appear to need some of the changes I made. I've checked the behavior
a bit in vanilla (emacs -q) Emacs 20 also.

Off hand, it looks like the only real (minor) improvements I made were 1)
the different faces for stem vs remainders and 2) sorting.

(I also use a modified old library called elect-mbuf.el, and I'm not 100%
sure that I don't still need some of my changes to adapt icomplete to that.)

Again, sorry for the confusion. See below.

 - Drew

-----Original Message-----
From: monnier@iro.umontreal.ca [mailto:monnier@iro.umontreal.ca]
Sent: Tuesday, April 13, 2004 3:37 PM
To: Drew Adams
Cc: Emacs-Devel
Subject: Re: icomplete.el enhancement


> * 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?

Yes, you're right; sorry for the confusion: Different faces is apparently
all I added here.

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

I'm not sure I understand the cycling. Are you thinking of applying a
most-recently used ordering, and then cycling the list?

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

I think you may be right. My definition of icomplete-exhibit is virtually
identical to the one in icomplete.el, except for this additional filter,
which inhibits action if the input starts with (, ", ', or a digit. This is
probably no longer needed.

(not (looking-at
"\\(\\s-+$\\|\\s-*\\(\\s(\\|\\s\"\\|\\s'\\|\\s<\\|[0-9]\\)\\)"))

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

Ditto. Probably no longer needed.