bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode

[Drew Adams]

> My point is, as long as ido and icomplete are used in completion 
> situations,

If you assume that Ido is used, then why use Icomplete too?

> and they're used to complete relatively short things,

Unwarranted assumption.  (Of course, it depends on your "relatively".)

And even when minibuffer content is relatively short, Isearch can be a quick way
to move around: think cursor movement, not search.

If you use Ido then you are perhaps not so used to editing and moving around the
minibuffer text.  But for those not using Ido, editing and moving around,
including with isearch, are not uncommon.

> they obviate the need for all three commands you're complaining about.

No, they don't.  And my complaint is not only about any particular three keys
you might choose to co-opt by default.  My beef is with co-opting any keys by
default.

Icomplete has a long, distinguished career helping Emacs users by passively
showing the available completions and not interfering with any minibuffer key
bindings (N.B. _any_).  It should continue to offer that service that it does so
well.

If you want to add an optional mode that offers other, Ido-like things, fine.
Just make it optional, please.

> Searching back and forward though a short input string is 
> quite useless,

See above.  Searching to move around the minibuffer might be useless in Ido.
But not everyone prefers to use Ido.

But again, it's not about the particular keys.  It's about stealing keys from
their usual use in the Emacs minibuffer.  Not the Ido minibuffer, which is quite
special and atypical, but the Emacs minibuffer, in general.

> >> I'd like to comment on this as a ido-mode user.
> >
> > Great.  But please recognize that not all Emacs users use 
> > Ido.  And it is not even the default minibuffer behavior for
> > Emacs.  And it is not even described in the Emacs manual.
> 
> Is icomplete described in the Emacs manual?

You're missing the point.  _Emacs_ is described in the Emacs manual.  This is
about the Emacs minibuffer.  Including the behavior you get from `emacs -Q'.
That minibuffer behavior is described in the manual, yes.

Icomplete has until now not interfered with that behavior, in particular with
whatever keys are available in the minibuffer, in whatever mode, from whatever
library, AFAIK.

Icomplete has always played well with whatever minibuffer bindings you might use
or prefer.  It has only provided passive help: info about available completions.

> I'm well-aware how Emacs looks and works by default, thank you very 
> much.  It also has a rich ecosystems with packages modifying 
> its behavior every which way, according to user needs and whims.

Good.  And until now, Icomplete has played well with all of those users and
their individual whims.

It has not imposed key bindings.  It should remain so well behaved and continue
to be useful whatever bindings might be in effect, from emacs -Q or from other
libraries.

It gets along with so many modes in large part because it is keyless: it just
provides info.  Nearly every mode can take advantage of it, regardless of how
that mode might define minibuffer behavior.

It is indeed about the many Emacs users and their whims, and not just the whims
of a developer or two.

Let users easily get your preferred behavior, sure, but let them just as easily
toggle that off and return to the bindings provided by emacs -Q or other
packages they might choose.

Why do you need to go all the way and impose your preferred behavior by default,
and leave fiddling with keymaps as the only way to restore the bindings that
would otherwise have remained current?

> >> this behavior allows you to "search" through the candidates.
> >
> > Yes, I know.  So what?  The point is that this substitutes 
> > the original, normal, usual behavior of those keys with another
> > behavior.
> 
> icomplete is off by default, so no user is forced to use the 
> non-default behavior.

The discussion is about Icomplete behavior.  The default behavior of Icomplete.
You are veering off the road.

> > You should not just assume, because you are an Ido enthusiast,
> > that all users now want to switch to an Ido-like behavior for
> > keys they have been able to use otherwise.
> 
> Do I come across as a five-year-old or something?

I'll have to let that one pass.

> >> this strikes me as more appropriate.
> >
> > So in your case you would opt in to use the keys.  What's 
> > the problem? (Though as an Ido user you really do not need
> > Icomplete at all, do you?)
> 
> I don't.  But you can make most of the same arguments in the 
> context of ido-mode, can't you?

If you do not need Icomplete then why do you need it to interact like Ido?

I do use Icomplete.  And I want it to play well, for me and others, with emacs
-Q and with other libraries that bind minibuffer keys.

And no, I certainly would not make ANY of the same arguments wrt Ido that I've
made about Icomplete.

Icomplete is a long established mode that provides completion information.  That
simple help function serves a useful purpose.  Until now Icomplete has not done
anything else.

Ido has from the beginning involved exceptional user interaction to choose
candidates.  It has never been something that you could use with the normal
(e.g. emacs -Q) minibuffer interaction or with other-library minibuffer
interactions.

Ido radically alters minibuffer interaction - it plays by its own rules.  It has
provided its own, alternative minibuffer UI from the beginning.  That is its
raison d'etre.  Nothing wrong with that; it is what Ido is intended to do.

Totally different from Icomplete.  You have not heard me make any suggestion
about changing Ido behavior.

> > You should get your way, for your own use.  Another user 
> > should be able to get the longstanding Icomplete behavior,
> > for her own use.
> 
> ...maybe except this one.  How long ago has this 
> "longstanding" behavior changed?

Cannot parse that.  Are you asking how old Icomplete is?  Or when the last
significant change in behavior was made to Icomplete?

If so, I don't know the answer, but my guess would be that Icomplete is still
essentially the same as it was designed to be, and it is quite old (decades).

If you are really interested, you can do the archaeology to find the answers to
what you are asking, whatever it is.

> > It should be easy for each to get the behavior preferred, 
> > and even to switch to the other behavior.
> >
> > This is trivial to implement.  What so much resistance to giving
> > users the choice?  Why so much insistence on bending Icomplete
> > to be Ido-like for all?   Users are free to use Ido if they like.
> > Where's the beef?
> 
> I believe most of the resistance is against your suggestion that the 
> minor mode with modified keybindings should be off by default.

That's truly good to hear.  So if we are agreed that users be able to easily
toggle the behavior on/off, instead of telling them to go roll their own if they
don't like the change, then let's move on to the question of the default: on or
off.

> If you hide nice things from users, some portion of users with never 
> find them. So, it hurts discoverability.

Wonderful features have a way of being discovered, and I am sure this will have
no problem in that regard.  Discoverability seems a big deal when someone wants
to announce their wonderful new feature - you want to make sure people don't
miss the new 2014 car model, so you advertise it.  Not needed here.  Emacs
advertises using NEWS, the manual, and menus.

More important here should be leaving Icomplete to do its great job of passively
showing help.  I am in favor of keeping the traditional behavior by default.

A non-Lisper who uses packages P and Q, which might bind some minibuffer keys,
should not need to get out the Elisp manual to try to find a way to restore the
bindings that P or Q provide, whenever Icomplete mode is turned on together with
P or Q.

By default, Icomplete should not change any minibuffer bindings.

But whichever behavior is the default is far and away secondary to the matter of
providing a quick toggle between the two behaviors.  That is my primary concern.


Even if we misguidedly let Icomplete impose bindings by default, a user should
see in the Icomplete doc string that she can just toggle on or off a secondary
mode that removes those bindings and restores whatever would be there otherwise.

S?he should not be looking up the Lisp code of P, and digging into the Elisp
manual, to find which keys to rebind and how, in order to get P's bindings each
time.