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

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

[Drew Adams]

Icomplete mode is general, for use with all minibuffers, whatever the
kind of input being done (kind of completion or input without
completion, etc.).  It needs to be sensitive to this and not impose
itself like a brute.  There are many minibuffer keymaps, with many keys
in them.  And applications often define more keys in these maps.
 
These Icomplete keybindings are inappropriate:
 
(defvar icomplete-minibuffer-map
  (let ((map (make-sparse-keymap)))
    (define-key map [?\M-\t] 'minibuffer-force-complete)
    (define-key map [?\C-j]  'minibuffer-force-complete-and-exit)
    (define-key map [?\C-s]  'icomplete-forward-completions)
    (define-key map [?\C-r]  'icomplete-backward-completions)
    map))
 
It is not kosher to bind such keys in the minibuffer in a general mode.
Let users bind them if they like.
 
In particular: C-s and C-r are used to search minibuffer text (e.g. move
the cursor).  M-TAB is useful in the minibuffer to complete names.  And
users and applications can reasonably bind C-j to be self-inserting in
the minibuffer, just as some do for SPC.
 
`icomplete-mode-map' should not even be unconditionally imposed as part
of the local map when Icomplete mode is turned on.
 
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.
 
I propose that you create a separate mode for using
`icomplete-mode-map', analogous to the separation between `cua-mode' and
`cua-selection-mode'.  That is clean and simple for you to do.
 
Users turning on Icomplete mode would not get these key bindings.  Users
turning on the new Icomplet-With-Cycling mode (or whatever name you
like) would get the current behavior you have defined: Icomplete plus
your keybindings.
 
This approach would give users more contol - an easy way to get your new
cycling feature or to do without it.  If they choose to use it, they can
always change the key bindings.  Even in that case, my suggestion would
be that you pick different default bindings.  But at least with this
approach no bindings would not be imposed on regular Icomplete users.
 
(defun cua-selection-mode (arg)
  "Enable CUA selection mode without the C-z/C-x/C-c/C-v bindings."
  (interactive "P")
  (setq-default cua-enable-cua-keys nil)
 ;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
  (if (not (called-interactively-p 'any))
      (cua-mode arg)
    ;; Use call-interactive to turn a nil prefix arg into `toggle'.
    (call-interactively 'cua-mode)
    (customize-mark-as-set 'cua-enable-cua-keys)))

In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2013-01-25 on ODIEONE
Bzr revision: 111604 eliz@gnu.org-20130125143821-1ykj7ia1qjojjjnp
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
 

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

[Jambunathan K]

> These Icomplete keybindings are inappropriate:
>  
> (defvar icomplete-minibuffer-map
>   (let ((map (make-sparse-keymap)))
>     (define-key map [?\M-\t] 'minibuffer-force-complete)
>     (define-key map [?\C-j]  'minibuffer-force-complete-and-exit)
>     (define-key map [?\C-s]  'icomplete-forward-completions)
>     (define-key map [?\C-r]  'icomplete-backward-completions)
>     map))
>  
> It is not kosher to bind such keys in the minibuffer in a general mode.
> Let users bind them if they like.

> In particular: C-s and C-r are used to search minibuffer text (e.g. move
> the cursor).  M-TAB is useful in the minibuffer to complete names.  And
> users and applications can reasonably bind C-j to be self-inserting in
> the minibuffer, just as some do for SPC.

You don't use ido-mode, do you?  These bindings mimic the behaviour of
ido-mode.  As a user, I can't be too concerned with the backend library
facilitating completions.

> `icomplete-mode-map' should not even be unconditionally imposed as part
> of the local map when Icomplete mode is turned on.

I don't see any `icomplete-mode-map'.

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

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.

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

> I propose that you create a separate mode for using
> `icomplete-mode-map', analogous to the separation between `cua-mode' and
> `cua-selection-mode'.  That is clean and simple for you to do.
>  
> Users turning on Icomplete mode would not get these key bindings.  Users
> turning on the new Icomplet-With-Cycling mode (or whatever name you
> like) would get the current behavior you have defined: Icomplete plus
> your keybindings.
>  
> This approach would give users more contol - an easy way to get your new
> cycling feature or to do without it.  If they choose to use it, they can
> always change the key bindings.  Even in that case, my suggestion would
> be that you pick different default bindings.  But at least with this
> approach no bindings would not be imposed on regular Icomplete users.
>  
> (defun cua-selection-mode (arg)
>   "Enable CUA selection mode without the C-z/C-x/C-c/C-v bindings."
>   (interactive "P")
>   (setq-default cua-enable-cua-keys nil)
>  ;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  
>   (if (not (called-interactively-p 'any))
>       (cua-mode arg)
>     ;; Use call-interactive to turn a nil prefix arg into `toggle'.
>     (call-interactively 'cua-mode)
>     (customize-mark-as-set 'cua-enable-cua-keys)))
>
> In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
>  of 2013-01-25 on ODIEONE
> Bzr revision: 111604 eliz@gnu.org-20130125143821-1ykj7ia1qjojjjnp
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> Configured using:
>  `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
>  -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'

-- 

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

[Dmitry Gutov]

"Drew Adams" <drew.adams@oracle.com> writes:

> Icomplete mode is general, for use with all minibuffers, whatever the
> kind of input being done (kind of completion or input without
> completion, etc.).

No, it's not, it's only used in specific cases.
For example, icomplete is not used in minibuffer during eval-expression.

> It needs to be sensitive to this and not impose
> itself like a brute.  There are many minibuffer keymaps, with many keys
> in them.  And applications often define more keys in these maps.
>  
> These Icomplete keybindings are inappropriate:
>  
> (defvar icomplete-minibuffer-map
>   (let ((map (make-sparse-keymap)))
>     (define-key map [?\M-\t] 'minibuffer-force-complete)
>     (define-key map [?\C-j]  'minibuffer-force-complete-and-exit)
>     (define-key map [?\C-s]  'icomplete-forward-completions)
>     (define-key map [?\C-r]  'icomplete-backward-completions)
>     map))
>  
> It is not kosher to bind such keys in the minibuffer in a general mode.
> Let users bind them if they like.

I'd like to comment on this as a ido-mode user.

> In particular: C-s and C-r are used to search minibuffer text (e.g.
> move

Instead of searching though the already entered text, this behavior
allows you to "search" through the candidates.
Since this mode is usually enabled when you're trying to write or pick a
single symbol, not a bunch of text, this strikes me as more appropriate.

> the cursor).  M-TAB is useful in the minibuffer to complete names.

Likewise, minibuffer-force-complete does complete the current symbol.
What's the problematic use case?

--Dmitry

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

[Stefan Monnier]

> It is not kosher to bind such keys in the minibuffer in a general mode.

Of course it is.  Most modes do that.

> Let users bind them if they like.

Instead, we provide a default set.  The user is still, as always, free
to add or remove bindings.
E.g. you might like to add (setq icomplete-minibuffer-map (make-sparse-keymap))
to your .emacs if you prefer the old behavior.


        Stefan

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)
> >  ;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

[Drew Adams]

> > Icomplete mode is general, for use with all minibuffers, 
> > whatever the kind of input being done (kind of completion
> > or input without completion, etc.).
> 
> No, it's not, it's only used in specific cases.
> For example, icomplete is not used in minibuffer during 
> eval-expression.

Nitpicking.  Completion.  That should have been understood from the context: "I
_complete_" mode.  Icompletion is about completion contexts.

> > Let users bind them if they like.
> 
> 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.

IOW, your parochial point of view is of course welcome and relevant, but please
don't mistake it for how users in general view using the minibuffer.

> > In particular: C-s and C-r are used to search minibuffer
> > text (e.g. move
> 
> Instead of searching though the already entered text,

("Already entered" does not necessarily mean typed, BTW.)

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

A given user can prefer either behavior: normal or new.  Let users choose
easily.  That's the point.

There are lots of Emacs users who have been using Icomplete for years (yes, even
before Ido existed), and appreciate its informative help.

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.

> 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?)

You should get your way, for your own use.  Another user should be able to get
the longstanding Icomplete behavior, for her own use.

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?

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

[Drew Adams]

> > It is not kosher to bind such keys in the minibuffer in a 
> > general mode.
> 
> Of course it is.  Most modes do that.

Icomplete is not a new mode.  Its use has been to provide informative help.  It
has never interfered with minibuffer bindings in its long history.

Even if Icomplete were new, we should separate the binding of keys out, making
that optional.  It should be easy to use Icomplete with all the existing
minibuffer bindings.

Introducing alternative minibuffer bindings for use with Icomplete mode is fine.
But they should be optional.

> > Let users bind them if they like.
> 
> The user is still, as always, free to add or remove bindings.
> E.g. you might like to add (setq icomplete-minibuffer-map 
> (make-sparse-keymap))
> to your .emacs if you prefer the old behavior.

Make it _easier_ on users.  Do what we've done for CUA mode and CUA selection
mode.

Let users easily separate the informative help aspect of Icomplete - what it has
always provided, from the addition of Ido-like cycling.

And do not have Icomplete trample minibuffer bindings by default.  Let users opt
in for that.

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

[Jambunathan K]

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

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

[Jambunathan K]

"Drew Adams" <drew.adams@oracle.com> writes:

> And do not have Icomplete trample minibuffer bindings by default.  Let users opt
> in for that.

Does Ido-like Icomplete mode interfere with any of your (existing?)
libraries?  If yes, then you make your case stronger.  For overall good,
you may want to describe how your libraries depend upon the "old"
icomplete behaviour.

Note that I have no opinion on whether cycling should be opt-in or
opt-out, by default.
-- 

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

[Drew Adams]

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

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

[Drew Adams]

> > And do not have Icomplete trample minibuffer bindings by 
> > default.  Let users opt in for that.
> 
> 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.

And it is general in that it is also wrt nearly any minibuffer behavior (not
just emacs -Q), from nearly any package, whether it be distributed by Emacs
(e.g. Ido, Viper) or not.  There is nothing in my argument that relates
specifically to any given package.

Until now, Icomplete has simply aided users passively, by showing the possibile
completions.  It has not in any way changed the behavior of the user's
interaction with the minibuffer (e.g. keys).

That should continue to be the default behavior: let Icomplete inform about
completions but not change the current minibuffer interaction (whatever that
might be, emacs -Q or otherwise).

Let Icomplete also offer an additional mode, like CUA does with CUA mode instead
of CUA selection mode, whereby it binds some cycling keys.  So much the better -
I'm glad you provided this feature.

> Note that I have no opinion on whether cycling should be opt-in or
> opt-out, by default.

I do.  It should be opt-in, so that Icomplete preserves, by default, whatever
minibuffer behavior is already present and preferred by the user.

There are many different minibuffer behaviors besides emacs -Q and Ido.  Some,
like Viper and Ido, are very different from emacs -Q.  Some are more similar to
emacs -Q.

The point is that a user's preferred minibuffer interaction should not be thrown
to the wind just because s?he turns on Icomplete mode.

And whether opt-in or opt-out, it should be trivial and clear for a user how to
toggle to the other behavior.

The code I sent lets you do that using a command/key.  No fiddling with keymaps
by users, etc.  If users want to change which keys are used for Icomplete
cycling, _then_ they can fiddle with the bindings.

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

[Dmitry Gutov]

On 04.02.2013 20:16, Drew Adams wrote:
>>> Icomplete mode is general, for use with all minibuffers,
>>> whatever the kind of input being done (kind of completion
>>> or input without completion, etc.).
>>
>> No, it's not, it's only used in specific cases.
>> For example, icomplete is not used in minibuffer during
>> eval-expression.
>
> Nitpicking.  Completion.  That should have been understood from the context: "I
> _complete_" mode.  Icompletion is about completion contexts.

It's in the name, but not in your statement above. As such, your 
statement was false. You also mentioned "input without completion", 
whatever that is.

My point is, as long as ido and icomplete are used in completion 
situations, and they're used to complete relatively short things, they 
obviate the need for all three commands you're complaining about.

Searching back and forward though a short input string is quite useless, 
and `minibuffer-complete' essentially conflicts with the main function 
of ido and icomplete: show the available candidates inline.

>>> Let users bind them if they like.
>>
>> 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?

> IOW, your parochial point of view is of course welcome and relevant, but please
> don't mistake it for how users in general view using the minibuffer.

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.

>>> In particular: C-s and C-r are used to search minibuffer
>>> text (e.g. move
>>
>> Instead of searching though the already entered text,
>
> ("Already entered" does not necessarily mean typed, BTW.)

Yes. Slightly less useless in this case, but this is a rare one, naturally.

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

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

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

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

> 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.
If you hide nice things from users, some portion of users with never 
find them. So, it hurts discoverability.

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.

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

[Jambunathan K]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > And do not have Icomplete trample minibuffer bindings by 
>> > default.  Let users opt in for that.
>> 
>> Does Ido-like Icomplete mode interfere with any of your (existing?)
>> libraries?
>
> Yes, but it is irrelevant.

How can you argue for a case without supporting documents?  Why
refuse the explicit call for evidence.

Whatever arguments you provide may not be relevant to this bug per-se,
but it will help others understand how bare-bones icomplete can be used.

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

[Drew Adams]

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

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

[Juri Linkov]

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

I for one just disabled `icomplete-mode' in ~/.emacs when it got
added ido keybindings, waiting in the hope that someone will implement
`icomplete-mode-without-ido-keybindings' :-)

Without ido keybindings `icomplete-mode' is useful to see all possible
completions to be able to decide what the minimal length of the
completion string is sufficient to type.

For instance, with the intention to run `grep-find' typing `M-x gr' shows
"gr(ep){| -find | -mode}" that hints that the shortest string to type is
"gr-f" which could be remembered as the shortest alias for "grep-find".

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

[Jambunathan K]

Juri Linkov <juri@jurta.org> writes:

>> I don't particularly or personally need any of the keys you propose to have
>> Icomplete bind, for any other purpose.
>
> I for one just disabled `icomplete-mode' in ~/.emacs when it got
> added ido keybindings, waiting in the hope that someone will implement
> `icomplete-mode-without-ido-keybindings' :-)
>
> Without ido keybindings `icomplete-mode' is useful to see all possible
> completions to be able to decide what the minimal length of the
> completion string is sufficient to type.

I would have started this paragraph with: "With or without ido
keybindings".  Ido keybindings only adds cycling, it doesn't mess with
the display.  It is not clear to me how "Without ido keybindings" makes
it "useful to see all completions" .

If you want bigger real-estate you can tweak the icomplete-separator
option.

> For instance, with the intention to run `grep-find' typing `M-x gr' shows
> "gr(ep){| -find | -mode}" that hints that the shortest string to type is
> "gr-f" which could be remembered as the shortest alias for "grep-find".

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

[Juri Linkov]

> I would have started this paragraph with: "With or without ido
> keybindings".  Ido keybindings only adds cycling, it doesn't mess with
> the display.

Yes, "with or without ido keybindings", icomplete-mode is a standalone feature
separate from ido keybindings.  As the node (info "(emacs) Minor Modes") says:

   * Icomplete mode displays an indication of available completions when
     you are in the minibuffer and completion is active.  *Note
     Completion Options::.

and also (info "(emacs) Completion Options"):

     Icomplete mode presents a constantly-updated display that tells you
  what completions are available for the text you've entered so far.

and the Commentary section in icomplete.el:

  ;; Prospective completions are concisely indicated within the
  ;; minibuffer itself, with each successive keystroke.

There is nothing in documentation that suggests icomplete-mode
was intended to add ido keybindings.

If you want to create its submode implementing a new feature
that makes it work like `ido', why not give it a new name like
`icomplete-ido-mode'?

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

[Jambunathan K]

Juri Linkov <juri@jurta.org> writes:

>> I would have started this paragraph with: "With or without ido
>> keybindings".  Ido keybindings only adds cycling, it doesn't mess with
>> the display.
>
> Yes, "with or without ido keybindings", icomplete-mode is a standalone feature
> separate from ido keybindings.  As the node (info "(emacs) Minor Modes") says:
>
>    * Icomplete mode displays an indication of available completions when
>      you are in the minibuffer and completion is active.  *Note
>      Completion Options::.
>
> and also (info "(emacs) Completion Options"):
>
>      Icomplete mode presents a constantly-updated display that tells you
>   what completions are available for the text you've entered so far.
>
> and the Commentary section in icomplete.el:
>
>   ;; Prospective completions are concisely indicated within the
>   ;; minibuffer itself, with each successive keystroke.
>
> There is nothing in documentation that suggests icomplete-mode
> was intended to add ido keybindings.

I am amused by the last paragraph.  I don't think the author of
Icomplete was a clarivoyant.

You seem to make a mistaken assumption that if something is left un-said
then that something ceases to exist.

> If you want to create its submode implementing a new feature
> that makes it work like `ido', why not give it a new name like
> `icomplete-ido-mode'?

Let me remind everyone: I made a proposal and it sailed through.

Drew has made a proposal and you have chimed in.  It is for the
maintainers to make a call on what to do about it.  I don't think my
opinion matters here (much).

Jambunathan K.

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

[Drew Adams]

> Let me remind everyone: I made a proposal and it sailed through.
> Drew has made a proposal and you have chimed in.  It is for the
> maintainers to make a call on what to do about it.  I don't think my
> opinion matters here (much).

Jamunathan, I don't understand your resistance to making your keybindings
optional, and making it simple for a user to toggle them on/off.  We haven't
seen any argument supporting such resistance, AFAICT.

IOW, I don't think that anyone (not I, in any case) opposes the addition of a
feature that allows keys to be bound to provide Ido-like cycling.

All we (I, at least) are requesting is that this be user-controlled in a simple
(trivial) way.  Why is that too much to ask, in your opinion (which does matter,
obviously)?

Requiring users to fiddle with the minibuffer keymaps using Lisp is a non
response.  A user might use one or more additional packages that change or add
minibuffer bindings, and s?he should not have to try to code up a way to restore
whatever bindings would have been in effect without yours.

Even with emacs -Q, users should not need to know Lisp to be able to quickly
undo your bindings.  Just please make it easy on users to get back the Icomplete
behavior they have long enjoyed and might still prefer.

And please keep that longstanding behavior as the default one.  I sense that
that too is what Juri is underlining by quoting descriptions of the original
behavior and the intentions behind it.

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

[Stefan Monnier]

> I for one just disabled `icomplete-mode' in ~/.emacs when it got
> added ido keybindings, waiting in the hope that someone will implement
> `icomplete-mode-without-ido-keybindings' :-)

(setq icomplete-minibuffer-map (make-sparse-keymap))

should do it.


        Stefan

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

[Drew Adams]

> > I for one just disabled `icomplete-mode' in ~/.emacs when it got
> > added ido keybindings, waiting in the hope that someone 
> > will implement `icomplete-mode-without-ido-keybindings' :-)
> 
> (setq icomplete-minibuffer-map (make-sparse-keymap))
> should do it.

Here's the point: Users should not have to do that.

Give them a simple toggle command, so they don't need to know Lisp and dig into
the Icomplete or other code to figure that out and fix things.

And please turn off the bindings by default.

What's the big deal?  This should be a no-brainer.

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

[Stefan Monnier]

>> I for one just disabled `icomplete-mode' in ~/.emacs when it got
>> added ido keybindings, waiting in the hope that someone will implement
>> `icomplete-mode-without-ido-keybindings' :-)
> (setq icomplete-minibuffer-map (make-sparse-keymap))
> should do it.

BTW, which of those keybindings do you find inconvenient?


        Stefan

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

[Juri Linkov]

>>> I for one just disabled `icomplete-mode' in ~/.emacs when it got
>>> added ido keybindings, waiting in the hope that someone will implement
>>> `icomplete-mode-without-ido-keybindings' :-)
>> (setq icomplete-minibuffer-map (make-sparse-keymap))
>> should do it.
>
> BTW, which of those keybindings do you find inconvenient?

`C-r' like in bash is useful to search for previous input in the history.
This is especially useful for frequently used long command names
for which it's difficult to find the shortest completion alias and
remember it, e.g. for the command `gnus-read-ephemeral-emacs-bug-group'
re-invoking it from the history is easy with just `M-x C-r gn RET RET'.

Another frequently used case is using `C-s C-w C-w' to put the completed
string into the search ring, exit Isearch, exit the minibuffer and
search the same string from the ring in another buffer with `C-s C-s'.

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

[Jambunathan K]

Juri Linkov <juri@jurta.org> writes:

>>>> I for one just disabled `icomplete-mode' in ~/.emacs when it got
>>>> added ido keybindings, waiting in the hope that someone will implement
>>>> `icomplete-mode-without-ido-keybindings' :-)
>>> (setq icomplete-minibuffer-map (make-sparse-keymap))
>>> should do it.
>>
>> BTW, which of those keybindings do you find inconvenient?
>
> `C-r' like in bash is useful to search for previous input in the history.
> This is especially useful for frequently used long command names
> for which it's difficult to find the shortest completion alias and
> remember it, e.g. for the command `gnus-read-ephemeral-emacs-bug-group'
> re-invoking it from the history is easy with just `M-x C-r gn RET RET'.

`completion-all-sorted-completions' prefers recent input history.  Once
you have `gnus-read-ephemeral-emacs-bug-group' in the command history,
it is likely to be the first of the few completions which you can pick
with one or more C-s-es.

One doesn't need to rely on traditional "C-r" exclusively to accomplish
the above work flow.

> Another frequently used case is using `C-s C-w C-w' to put the completed
> string into the search ring, exit Isearch, exit the minibuffer and
> search the same string from the ring in another buffer with `C-s C-s'.

Can you tell me why this is "frequent"? May be you use this to jump to a
command name in a *.el file.

May be, there is a stronger case for "C-s" to be re-considered.
Whatever is decided, I would expect that ido and icomplete share the
same keys for cycling back and forth.
-- 

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

[Juri Linkov]

> `completion-all-sorted-completions' prefers recent input history.  Once
> you have `gnus-read-ephemeral-emacs-bug-group' in the command history,
> it is likely to be the first of the few completions which you can pick
> with one or more C-s-es.
>
> One doesn't need to rely on traditional "C-r" exclusively to accomplish
> the above work flow.

IIUC, it matches only prefixes, whereas traditional Isearch `C-r'
can also match in the middle of the command name in the history.

When I tried now `icomplete-backward-completions' currently bound to `C-r',
I discovered that it is broken.  It fails with the error:

Debugger entered--Lisp error: (wrong-type-argument listp 0)
  cdr(0)
  (setcdr last-but-one (cdr last))
  (progn (setcdr last-but-one (cdr last)) ...)
  (if last (progn (setcdr last-but-one (cdr last)) ...))
  (let* ((comps (completion-all-sorted-completions))  (last (cdr last-but-one))) ...)
  icomplete-backward-completions()
  call-interactively(icomplete-backward-completions nil nil)
  read-from-minibuffer("M-x " nil ... nil extended-command-history nil nil)
  completing-read-default("M-x " ... commandp t nil extended-command-history nil nil)
  completing-read("M-x " ... commandp t nil extended-command-history)
  read-extended-command()
  byte-code("..." [current-prefix-arg read-extended-command] 2)
  call-interactively(execute-extended-command nil nil)

The full test case:

0. emacs -Q
1. M-x icomplete-mode RET
2. M-x icomplete-m C-r

Does this mean that other users of `icomplete-mode' like me disabled
`icomplete-mode' in their .emacs after it began overriding Isearch keys,
so this feature remained untested and the bug remained unnoticed
for the long time (2 months)?  I won't be surprised if this is
the real reason, because traditional Isearch C-s and C-r is useful
in the minibuffer.

OTOH, I believe the users of `icomplete-mode' might like the new feature
provided by the new commands `icomplete-forward-completions' and
`icomplete-backward-completions' only when it leaves intact the
traditional Isearch keybindings C-s and C-r.

Let's face the root of the problem: abusing C-s and C-r keys in ido was
a poor choice in the first place that paved the road to future conflicts.
Are there know alternatives to C-s and C-r among the ido users?
I see that ido.el mentions the right and left arrow keys.
Could they be used with some modifiers?

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

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

Juri Linkov <juri@jurta.org> writes:

>> `completion-all-sorted-completions' prefers recent input history.  Once
>> you have `gnus-read-ephemeral-emacs-bug-group' in the command history,
>> it is likely to be the first of the few completions which you can pick
>> with one or more C-s-es.
>>
>> One doesn't need to rely on traditional "C-r" exclusively to accomplish
>> the above work flow.
>
> IIUC, it matches only prefixes, whereas traditional Isearch `C-r'
> can also match in the middle of the command name in the history.
>
> When I tried now `icomplete-backward-completions' currently bound to `C-r',
> I discovered that it is broken.  It fails with the error:
>
> Debugger entered--Lisp error: (wrong-type-argument listp 0)
>   cdr(0)
>   (setcdr last-but-one (cdr last))
>
> The full test case:
>
> 0. emacs -Q
> 1. M-x icomplete-mode RET
> 2. M-x icomplete-m C-r


[-- Attachment #2: icomplete.el.diff --]
[-- Type: text/plain, Size: 1393 bytes --]

=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2013-02-07 08:50:04 +0000
+++ lisp/ChangeLog	2013-02-07 10:11:32 +0000
@@ -1,3 +1,8 @@
+2013-02-07  Jambunathan K  <kjambunathan@gmail.com>
+
+	* icomplete.el (icomplete-forward-completions)
+	(icomplete-backward-completions): Handle corner case (bug#13602).
+
 2013-02-07  Michael Albinus  <michael.albinus@gmx.de>
 
 	* vc/vc-hooks.el (vc-find-file-hook): `buffer-file-truename' can

=== modified file 'lisp/icomplete.el'
--- lisp/icomplete.el	2013-01-04 08:20:49 +0000
+++ lisp/icomplete.el	2013-02-07 10:01:09 +0000
@@ -167,8 +167,9 @@ Second entry becomes the first and can b
   (interactive)
   (let* ((comps (completion-all-sorted-completions))
 	 (last (last comps)))
+    (when comps
     (setcdr last (cons (car comps) (cdr last)))
-    (completion--cache-all-sorted-completions (cdr comps))))
+      (completion--cache-all-sorted-completions (cdr comps)))))
 
 (defun icomplete-backward-completions ()
   "Step backward completions by one entry.
@@ -178,7 +179,7 @@ Last entry becomes the first and can be
   (let* ((comps (completion-all-sorted-completions))
 	 (last-but-one (last comps 2))
 	 (last (cdr last-but-one)))
-    (when last
+    (when (consp last)			; Atleast two elements in comps
       (setcdr last-but-one (cdr last))
       (push (car last) comps)
       (completion--cache-all-sorted-completions comps))))


[-- Attachment #3: Type: text/plain, Size: 1427 bytes --]


> Does this mean that other users of `icomplete-mode' like me disabled
> `icomplete-mode' in their .emacs after it began overriding Isearch keys,
> so this feature remained untested and the bug remained unnoticed
> for the long time (2 months)?  I won't be surprised if this is
> the real reason, because traditional Isearch C-s and C-r is useful
> in the minibuffer.

Interesting to learn that disabling of `icomplete-mode' might have been
an un-intentional side-effect rather than a deliberate act.  Interesting
to see how this exchange is developing.

> OTOH, I believe the users of `icomplete-mode' might like the new feature
> provided by the new commands `icomplete-forward-completions' and
> `icomplete-backward-completions' only when it leaves intact the
> traditional Isearch keybindings C-s and C-r.

Let's have best of both worlds rather than label the unknown and strange
world as hell.

> Let's face the root of the problem: abusing C-s and C-r keys in ido was
> a poor choice in the first place that paved the road to future
> conflicts.

Fair statement.

> Are there know alternatives to C-s and C-r among the ido users?

I use C-s and C-r myself.

> I see that ido.el mentions the right and left arrow keys.
> Could they be used with some modifiers?

This would mean that my right hand is leaving the home row.  Any
suggestions ...  ISearch map is really a big rock that leaves little
room for even pebbles...

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

[Stefan Monnier]

> Does this mean that other users of `icomplete-mode' like me disabled
> `icomplete-mode' in their .emacs after it began overriding Isearch keys,
> so this feature remained untested and the bug remained unnoticed
> for the long time (2 months)?

I don't think so: the commands work(ed) in "most" cases.

> I won't be surprised if this is the real reason, because traditional
> Isearch C-s and C-r is useful in the minibuffer.

I suspect most users of icomplete who didn't follow the emacs-devel list
just didn't notice the change because they never/rarely use C-s and C-r in
the minibuffer.

> Let's face the root of the problem: abusing C-s and C-r keys in ido was
> a poor choice in the first place that paved the road to future conflicts.

I don't know if it was a poor choice, given that IDO tends to move away
from the idea that the minibuffer is just a normal buffer with normal
editing commands.

> I see that ido.el mentions the right and left arrow keys.
> Could they be used with some modifiers?

I think it's a good idea to try and use something else than C-s C-r,
since admittedly they collide with existing usage.  But the problem is
indeed to find other bindings.

We could use arrows with modifiers: by default, M-left and C-left do the
same thing, so we could use either C-left/C-right or M-left/M-right.

Another option that stays closer to IDO (and to home row) is M-s and M-r
(M-r's move-to-window-line-top-bottom is fairly useless in the
minibuffer, but M-s is normally a prefix key for search commands, so
it's not ideal, tho it's less severe than overriding C-s).


        Stefan

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

[Jambunathan K]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I see that ido.el mentions the right and left arrow keys.
>> Could they be used with some modifiers?
>
> I think it's a good idea to try and use something else than C-s C-r,
> since admittedly they collide with existing usage.  But the problem is
> indeed to find other bindings.
>
> We could use arrows with modifiers: by default, M-left and C-left do the
> same thing, so we could use either C-left/C-right or M-left/M-right.
>
> Another option that stays closer to IDO (and to home row) is M-s and M-r
> (M-r's move-to-window-line-top-bottom is fairly useless in the
> minibuffer, but M-s is normally a prefix key for search commands, so
> it's not ideal, tho it's less severe than overriding C-s).

How about C-S-s and C-S-r?  I just need to have Shift key depressed,
which is fine with me.

    (define-key map [?\C-\S-s]  'icomplete-forward-completions)
    (define-key map [?\C-\S-r]  'icomplete-backward-completions)

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

[Stefan Monnier]

> How about C-S-s and C-S-r?  I just need to have Shift key depressed,
> which is fine with me.

>     (define-key map [?\C-\S-s]  'icomplete-forward-completions)
>     (define-key map [?\C-\S-r]  'icomplete-backward-completions)

I'm not very much in favor:
- in my environment, C-S-r works but C-S-s is not received by Emacs
  (maybe XFCE catches it?).
- it won't work in ttys.
- I find it cumbersome to type.
None of them are deal breakers.


        Stefan

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

[Drew Adams]

Ironic.  The imposition of key bindings on Icomplete is being promoted by Ido
enthusiasts who have no real need for it since they use Ido, which does the same
thing.

Who does use Icomplete, and who will thus receive this gift not needed by its
donors?  Users who _do_ edit minibuffer contents.

Icomplete is really for non-Ido users.  It is used in an ordinary, non-Ido
minibuffer.  Imposing Ido keys on it (as opposed to just offering them as an
option), and thus taking away normal editing keys, is questionable, if not
misquided.  Why this is being promoted so forcefully by people who presumably
will not use Icomplete is a wonder.

It makes little difference which keys are chosen for these bindings.  Whatever
they are, they can conflict with keys used otherwise in the minibuffer, whether
those keys come from bare emacs -Q or from some other code.

I don't understand the refusal to let users choose easily whether they want
Icomplete to bind keys.  What's the problem with that?  I've asked this several
times and not once gotten an answer.  Why the avoidance to confront the question
head-on?

Instead of presenting reasons why this choice should be refused (only silence
there so far), there are attempts to divert the argument to how particular keys
are used - essentially a red herring.

When Juri mentions C-r and C-s, we get a lecture on how one can work around the
problem, Ido-style.

 > One doesn't need to rely on traditional "C-r" exclusively to
 > accomplish the above work flow.

Need?  Rely?  Exclusively?  Shades of "Let them eat cake".

Ultimately, we get some admission that maybe C-s and C-r are not the best
choices after all...  So the diversion turns to a search for other keys
(C-S-s...).

It does not matter here how Juri uses C-s or any other key - whether he really
"needs" to or how frequently he does so.  It does not matter whether Ido users
have found some other nifty way to accomplish the same thing as this or that
ordinary editing practice.

Some users _do_ edit, search, copy, and otherwise do things to their minibuffer
input.  And there is _no reason_ to try to shoehorn all such practice into an
Ido shoe.  No reason to present workarounds demonstrating that you can really do
whatever you want in spite of the imposition of Ido keys.

No need for any of that - just make the bindings optional, please. 

Ido does not use the minibuffer in the usual way at all.  Its keys and its
behavior are special, unusual, atypical for Emacs.

But more importantly, the problem is not this or that key.  The problem is
binding any keys at all and not giving users a simple way to do without such
bindings.

How about it?  Why not give users an option, and a toggle command?

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

[Juri Linkov]

> +2013-02-07  Jambunathan K  <kjambunathan@gmail.com>
> +
> +	* icomplete.el (icomplete-forward-completions)
> +	(icomplete-backward-completions): Handle corner case (bug#13602).

Thanks, your fix is now installed in trunk.

> How about C-S-s and C-S-r?  I just need to have Shift key depressed,
> which is fine with me.
>
>     (define-key map [?\C-\S-s]  'icomplete-forward-completions)
>     (define-key map [?\C-\S-r]  'icomplete-backward-completions)

Such compromise keys do not do any good neither to ido users
nor to non-ido users.

Better would be to add an option like `icomplete-enable-ido-keys' that
when set to t will define ido-specific bindings on `C-s' and `C-r'.

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

[Juri Linkov]

> I think it's a good idea to try and use something else than C-s C-r,
> since admittedly they collide with existing usage.  But the problem is
> indeed to find other bindings.
>
> We could use arrows with modifiers: by default, M-left and C-left do the
> same thing, so we could use either C-left/C-right or M-left/M-right.

I perceive the `icomplete-mode' feature as a way to select a completion
without opening the list of completions in the *Completions* buffer.

Since the list of completions can be opened from the minibuffer by typing
<prior> or `M-v' (`switch-to-completions') and selecting a completion
with <left> `previous-completion' and <right> `next-completion'
(whereas `C-f' and `C-b' retain their traditional keybindings),
e.g. to select `list-buffers' one could type:

`M-x list- <prior> <right> <right> RET'

so it would be reasonable to use something similar in icomplete:

`M-x list- <C-right> <C-right> C-j'

(the advantage is that the user doesn't have to release the Control key)

or also

`M-x list- <C-right> <C-right> C-RET'

(interesting that `C-RET' is already translated to `C-j' on ttys by default
but not on X, so a separate keybinding is necessary for C-RET on X
for `minibuffer-force-complete-and-exit' currently bound to `C-j'.)

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

[Stefan Monnier]

> `M-x list- <C-right> <C-right> C-RET'

So you're voting for C-left/C-right?  OK, noted.

> (interesting that `C-RET' is already translated to `C-j' on ttys by default
> but not on X,

In my xterm, when I hit C-RET I get "<C-return> is undefined", so it's not
the case for all ttys.


        Stefan

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

[Drew Adams]

> > How about C-S-s and C-S-r?  I just need to have Shift key depressed,
> > which is fine with me.
> >
> >     (define-key map [?\C-\S-s]  'icomplete-forward-completions)
> >     (define-key map [?\C-\S-r]  'icomplete-backward-completions)
> 
> Such compromise keys do not do any good neither to ido users
> nor to non-ido users.

Agreed.  But Ido users presumably do not need Icomplete anyway.  It is non-Ido
users that we should be concerned about for Icomplete.

> Better would be to add an option like `icomplete-enable-ido-keys' that
> when set to t will define ido-specific bindings on `C-s' and `C-r'.

Yes, but without "ido" in the name.  It is about enabling keys (any keys) for
Icomplete.  It is not about enabling Ido keys for Icomplete.

The keys to use by default can be whatever you like, but they should be specific
to Icomplete (i.e., in its own, independent keymap, as now).

I.e., even if the keys used by default are identical to those used in Ido by
default, there should be no other connection.  Since users will be free to
change them in either place separately, the option name should be unrelated to
Ido.

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

[Drew Adams]

> > `M-x list- <C-right> <C-right> C-RET'
> 
> So you're voting for C-left/C-right?  OK, noted.

Also not great.  Removes two useful editing keys from the minibuffer
(`backward-word', `forward-word').

But again, if the use of keys is optional and easily toggled, and especially if
it is turned off by default, then it doesn't matter so much which keys you
choose.

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

[Jambunathan K]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > `M-x list- <C-right> <C-right> C-RET'
>> 
>> So you're voting for C-left/C-right?  OK, noted.
>
> Also not great.  Removes two useful editing keys from the minibuffer
> (`backward-word', `forward-word').

M-x where-is RET tells me there is an escape route.

backward-word is on M-b, ESC <left>
forward-word is on M-f, ESC <right>

> But again, if the use of keys is optional and easily toggled, and especially if
> it is turned off by default, then it doesn't matter so much which keys you
> choose.

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

[Drew Adams]

> >> So you're voting for C-left/C-right?  OK, noted.
> >
> > Also not great.  Removes two useful editing keys from
> > the minibuffer (`backward-word', `forward-word').
> 
> M-x where-is RET tells me there is an escape route.
> backward-word is on M-b, ESC <left>
> forward-word  is on M-f, ESC <right>

More workaround advice.  But yes, these keys are so useful that emacs -Q binds
them by default to multiple key sequences.  Users have various use patterns.

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

[Jambunathan K]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> How about C-S-s and C-S-r?  I just need to have Shift key depressed,
>> which is fine with me.
>
>>     (define-key map [?\C-\S-s]  'icomplete-forward-completions)
>>     (define-key map [?\C-\S-r]  'icomplete-backward-completions)
>
> I'm not very much in favor:
> - in my environment, C-S-r works but C-S-s is not received by Emacs
>   (maybe XFCE catches it?).
> - it won't work in ttys.
> - I find it cumbersome to type.
> None of them are deal breakers.

We seem to be settling on C-left and C-right.

That said, how about

     C-, and C-. (C-< and C->)

No need to move away from Home Row and the less/greater symbols can
serve as directional cues for rote learning.

>
>
>         Stefan

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

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>>> > `M-x list- <C-right> <C-right> C-RET'
>>> 
>>> So you're voting for C-left/C-right?  OK, noted.
>>
>> Also not great.  Removes two useful editing keys from the minibuffer
>> (`backward-word', `forward-word').
>
> M-x where-is RET tells me there is an escape route.
>
> backward-word is on M-b, ESC <left>
> forward-word is on M-f, ESC <right>

I have opened a new bug and put my offerings there.

See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13708

>> But again, if the use of keys is optional and easily toggled, and especially if
>> it is turned off by default, then it doesn't matter so much which keys you
>> choose.

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

[Lars Ingebrigtsen]

I think the conclusion here was that we do not want to change the key
bindings for icomplete.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

> I think the conclusion here was that we do not want to
> change the key bindings for icomplete.

Amazing conclusion to be drawn from this discussion.
Oh well.