[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - mak
From: |
Jambunathan K |
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
> 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'
--