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

[Drew Adams]

> You don't use ido-mode, do you?

No, thank you.  And it is not the default behavior for Emacs either.  You won't
even find it described in the Emacs manual, where the minibuffer is described in
detail.

The real question is "Have you used Emacs (and Icomplete) without Ido mode?"
That's the use case I'm concerned about.

If you wear Ido-colored glasses when thinking about this then you will likely
not see clearly that a user can want these keys to be left alone, to be used
otherwise, as before.

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

Regardless, these keys should be optional for Icomplete.  Icomplete is not Ido.


> As a user, I can't be too concerned with the 
> backend library facilitating completions.

In changing Icomplete for all users you are acting as an Emacs developer, not
just as one user.

And the concern for users is not dependent on any backend libraries.

`emacs -Q' does not put you in Ido mode, and it lets you use all kinds of keys
in the minibuffer, including C-s and C-r.  Icomplete should continue to be
compatible with this, if a user so prefers.

Users can prefer not to have Icomplete bind such keys, to keep Icomplete for
what it was originally designed (informative help), and to allow those keys to
be used otherwise in the minibuffer, just as before.

The minibuffer is a buffer where you can _edit_ your input.  That Ido restricts
the minibuffer behavior, removing this editing possibility (well, restricting it
modally), is a specialty of Ido - it is not the normal behavior of the Emacs
minibuffer.

The minibuffer is much bigger in behavior and possibilities than what Ido allows
for.  Nothing wrong with Ido doing what it does to the minibuffer, for its own
purposes.  But that's not the Emacs minibuffer, in general.

And Icomplete has always been compatible with the general, emacs -Q, minibuffer.
This should continue, at least as the default behavior.

These key bindings should be optional, in a separate mode, just as for CUA mode
and CUA Selection mode.

Let me be clear.  I have nothing against Ido or against the keys you defined for
use with Icomplete.  I believe that both can be useful, and I applaud your
addition of the keys to Icomplete.  The point is that they should be optional.

Turning on Icomplete mode should not suddenly remove the possibility of using
these or any other keys in the minibuffer for their normal behavior.

> Does playing around with `icomplete-minibuffer-setup-hook'
> help with getting the behaviour you want?

Users should not need to so play around.

> In `icomplete-minibuffer-setup', should setting up of composed map be
> delayed until after the `icomplete-minibuffer-setup' had a chance to
> run?  I am posing this as a question, for you have better 
> understanding of keymaps than I do.

I seriously doubt that I have a better understanding of keymaps than you do.

What should be done is to put the binding of such keys into a separate, optional
mode.  Keep Icomplete mode for what it was intended (information display), and
add a mode on top of it that additionally provides the Ido-like keys.  Simple,
friendly to users, no change of the minibuffer keys unless you want it.

Here is what I do, in case it helps.  (The only reason for the mode var defvar
and the eval here is so the code will work also with older Emacs versions.  If
integrated with icomplete.el such code could be greatly simplified.)

(defvar icompletep-ORIG-icomplete-minibuffer-map)
(defvar icompletep-cycling-mode nil)

(when (boundp 'icomplete-minibuffer-map) ; Emacs 24.4+
  (setq icompletep-ORIG-icomplete-minibuffer-map
        icomplete-minibuffer-map ; Save it and wipe it out.
        icomplete-minibuffer-map  nil)
  (eval '(define-minor-mode icompletep-cycling-mode
          "Icomplete, with cycling keys enabled if on, disabled if off.
If off then the cycling keys of Icomplete mode are free for their
normal minibuffer uses.  The default Icomplete-mode cycling keys are:

M-TAB\t- complete to exact match, repeat to cycle
C-j\t- complete to first match and exit minibuffer
C-s\t- cycle first entry to end
C-r\t- cycle last entry to start

If you want Icomplete cycling behavior but do not want to use these
keys for it, customize the bindings in `icomplete-minibuffer-map'.

Turning this mode on also turns on Icomplete mode.
Turning it off does not turn Icomplete mode on or off."
          nil nil nil
          (when icompletep-cycling-mode (icomplete-mode 99))
          (setq icomplete-minibuffer-map
           (and icompletep-cycling-mode
            icompletep-ORIG-icomplete-minibuffer-map))))
  (icompletep-cycling-mode -99))

A user wanting the behavior you want need only turn on `icompletep-cycling-mode'
instead of `icomplete-mode'.

What's more, a user can bind the mode to a key, to easily toggle the cycling
keys on/off, without leaving Icomplete mode.

> > You have made it difficult for users to get the normal, traditional
> > Icomplete behavior without your recent additions for cycling.
> > Misguided.  Please let users more easily choose whether 
> > they want that.
> 
> May be we should wait until one another user complains about hijacking
> of search keys to useless ends.

Why?  Why not return Icomplete to what it was and give Ido-oriented users an
easy choice to get the behavior you like?  It is simple to do that.

And I never said that you were "hijacking" these keys to "useless ends".  The
ends you propose are useful.  But they should be optional, as these keys can
also be useful with their usual (or with other) bindings.

I am in favor of the addition of the possibility of cycling to Icomplete mode.
But it should be optional; that's all.

The model of CUA mode and CUA selection modes should serve here: Use another
mode if you want the cycling keys in addition to the information behavior of
Icomplete.  Key "hijacking" off by default, for Icomplete mode.

> >   (setq-default cua-enable-cua-keys nil)
> >  ;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^