From: Jambunathan K <kjambunathan@gmail.com>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 13602@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 [thread overview]
Message-ID: <87lib4e5m4.fsf@gmail.com> (raw)
In-Reply-To: <65EEA895D8A0443A859A780AB233146E@us.oracle.com> (Drew Adams's message of "Thu, 31 Jan 2013 11:41:44 -0800")
> 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'
--
next prev parent reply other threads:[~2013-02-04 10:27 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-31 19:41 bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode Drew Adams
2013-02-04 10:27 ` Jambunathan K [this message]
2013-02-04 16:02 ` Drew Adams
2013-02-04 16:36 ` Jambunathan K
2013-02-04 17:34 ` Drew Adams
2013-02-04 11:20 ` Dmitry Gutov
2013-02-04 16:16 ` Drew Adams
2013-02-04 22:04 ` Dmitry Gutov
2013-02-04 23:33 ` Drew Adams
2013-02-04 14:51 ` Stefan Monnier
2013-02-04 16:22 ` Drew Adams
2013-02-04 16:43 ` Jambunathan K
2013-02-04 17:40 ` Drew Adams
2013-02-05 2:35 ` Jambunathan K
2013-02-05 4:29 ` Drew Adams
2013-02-05 23:19 ` Juri Linkov
2013-02-06 3:42 ` Jambunathan K
2013-02-06 10:24 ` Juri Linkov
2013-02-06 13:31 ` Jambunathan K
2013-02-06 15:27 ` Drew Adams
2013-02-06 15:42 ` Stefan Monnier
2013-02-06 15:49 ` Drew Adams
2013-02-06 16:02 ` Stefan Monnier
2013-02-06 23:45 ` Juri Linkov
2013-02-07 3:51 ` Jambunathan K
2013-02-07 7:50 ` Juri Linkov
2013-02-07 10:24 ` Jambunathan K
2013-02-08 7:55 ` Juri Linkov
2013-02-08 16:55 ` Drew Adams
2013-02-07 14:17 ` Stefan Monnier
2013-02-07 15:45 ` Jambunathan K
2013-02-07 16:50 ` Stefan Monnier
2013-02-10 4:15 ` Jambunathan K
2013-02-07 21:32 ` Drew Adams
2013-02-08 7:59 ` Juri Linkov
2013-02-08 15:40 ` Stefan Monnier
2013-02-08 17:00 ` Drew Adams
2013-02-08 17:11 ` Jambunathan K
2013-02-08 17:28 ` Drew Adams
2013-02-13 14:42 ` Jambunathan K
2016-04-28 22:25 ` Lars Ingebrigtsen
2016-04-29 16:05 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lib4e5m4.fsf@gmail.com \
--to=kjambunathan@gmail.com \
--cc=13602@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.