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

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

> >> Does Ido-like Icomplete mode interfere with any of your
> >> (existing?) libraries?
> >
> > Yes, but it is irrelevant.  I am not arguing wrt any other
> > libraries.  The argument is general.  It is wrt emacs -Q
> > and its normal, default minibuffer behavior.
> 
> How can you argue for a case without supporting documents?
> Why refuse the explicit call for evidence.

It's not about me.  It's not about any libraries I might use.  I could as easily
and as honestly have answered your question with "No, and it is irrelevant."

I don't particularly or personally need any of the keys you propose to have
Icomplete bind, for any other purpose.

For my own use, the problem does not exist.  I've already added a mode to
separate the cycling behavior from the show-completions behavior - au choix.  I
sent the code for that, as an example.  That's reasonable, IMO.

It's about Emacs users generally, and Icomplete generally.  Icomplete has played
a useful role for a long time, usable in combination with emacs -Q and with any
other code that binds any keys in the minibuffer.

That's pretty darn useful.  Icomplete's lack of key bindings is an important
feature, one that lets it fit in.  It is apparently this point that you are not
getting.  You appear to be focused on your new feature and not appreciating
Icomplete for the simplicity it offers.

That feature of getting along with others is now thrown to the wind because you
want to add another feature that compromises it.  All I am suggesting is that we
keep that useful feature and provide your bells and whistles as an
easy-to-use-easy-to-refuse option.  What's wrong with that?

It's about keeping Icomplete so that it plays well with emacs -Q and with any
minibuffer key bindings that any user might have, bindings existing today or
tomorrow, coming from anywhere.

That should be the default.  If Icomplete is now going to provide a mode where
it adds its own bindings, which obviously could conflict with other bindings,
then that mode should be optional, and preferably not be the default Icomplete
behavior.

Until now, Icomplete has not had a behavior wrt keys.  You want to give it an
Ido-like behavior.  I say fine, make that an option, so the good ol' Icomplete,
which imposes no key behavior, is still there as the default.

I would have said the same thing if the proposal were to give Icomplete a
Viper-like key behavior, or an Icicles-like key behavior, or an mcomplete.el key
behavior, or a minibuffer-complete-cycle.el key behavior, or a cycle-mini.el key
behavior, or a Helm key behavior, or a timid.el key behavior, or Suzy
Creamcheese's custom minibuffer key behavior, or any other minibuffer key
behavior.

The point is to keep Icomplete simple and informational, having nothing to do
with keys, so that it plays well with any completion minibuffer - by default.