bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - mak


From: Drew Adams
Subject: bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode
Date: Mon, 4 Feb 2013 09:34:39 -0800

> >> These bindings mimic the behaviour of ido-mode.
> >
> > Yes, I know.  (Actually, it is Ido that mimicked Icomplete 
> > and IswitchB.)
> >
> > If you want Ido then you do not really need Icomplete anyway.
> 
> Are you saying: "ido can do what Icomplete does *without* the user
> modifying any of the completing-read calls in existing libraries?".
> 
> I remember modifying `completing-read-function' at some point in time.

Sorry, I don't know.  My impression was that Ido offers what is offered by
Icomplete + the new keys.

Whether it offers that out of the box is another question.

* If not, and if you want it to do that out of the box, then it is Ido mode that
should be modified.

* If not, and if you want that to be optional but not turned on by default, then
that too should be done for Ido mode itself, as opposed to being done for
Icomplete mode.

Again, I am not at all opposed to adding these keys to Icomplete mode as an
optional, Ido-like behavior.  I am in favor it.  The key word, however, is
"optional".

I would prefer that (a) the default behavior not change any minibuffer
keybindings and (b) that users can choose to toggle the key bindings on/off
easily, as a separate mode.  This is simple to implement and simple and clear
for users to make use of.

And no, by "optional" I do not mean that it is enough to tell users to go take a
hike and fiddle with Lisp code (e.g. key bindings), to restore the passive,
informative-only Icomplete that they've known and loved for decades, and that
has always cohabited well with pretty-much any Emacs minibuffer behavior.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]