bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Drew Adams
Subject: bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode
Date: Thu, 31 Jan 2013 11:41:44 -0800

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'
 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]