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

Previous Next

Full log

View this message in rfc822 format

From: Jambunathan K <kjambunathan <at> gmail.com>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 13602 <at> debbugs.gnu.org
Subject: bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode
Date: Mon, 04 Feb 2013 15:57:31 +0530

> 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 <at> 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'

-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.