[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: icomplete.el enhancement
From: |
Drew Adams |
Subject: |
RE: icomplete.el enhancement |
Date: |
Tue, 13 Apr 2004 16:38:49 -0700 |
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: address@hidden [mailto:address@hidden
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.