unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Gregory Heytings <gregory@heytings.org>
Cc: "47699@debbugs.gnu.org" <47699@debbugs.gnu.org>
Subject: bug#47699: [External] : bug#47699: [PATCH] Improve completion-list-mode-map
Date: Sun, 11 Apr 2021 22:33:42 +0000	[thread overview]
Message-ID: <SA2PR10MB4474F57D5514A345FA91366EF3719@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <3755fe92dca3dc533085@heytings.org>

> > FWIW, my voice says don't do any of this.  Just leave keymap
> > `completion-list-mode-map' alone.
> 
> Why?  Almost no keys are defined in completion-list-mode-map,
> so why would it not be okay to define a few of them?

I didn't say it isn't okay.  It's okay, of course.
I prefer that you don't; that's all.

I bind keys in it.  The more vanilla keys Emacs
binds there, the more I'll need to worry about
changing default bindings, and the more new users
will perhaps expect vanilla keys.

> > (Likewise, the minibuffer keymaps.)
> 
> Why?

Same reason - but a thousand times stronger.
Much more time (in Icicles) is spent in the
minibuffer than is ever spent in *Completions* -
thousands, maybe millions more key uses there
(not even counting self-inserting keys).

> And as I just said, if some object against M-c (as you just did),
> M-g is the other choice, its meanings in global-map can't be used 
> in the minibuffer.

Its global meanings can't be used in the minibuffer,
but other, minibuffer-specific meanings can.  I bind
lots of keys, including `M-g', in the minibuffer maps
(for Icicle minor mode).

The logic you're following, that key XYZ is "free",
and that its global binding is useless in the
minibuffer, is fine.  It's the same logic that others,
3rd-party libraries, use.  It's yet another case of
Emacs conquering more territory for itself, leaving
less for 3rd-party code.

Yes, I know things are different for a minor-mode
map.  Nothing prevents Icicle mode from continuing
with the same bindings.  Still, I'd prefer that
Emacs leave it alone - as it has done for 40 years. 

> C-<insert> doesn't exist on laptop keyboard, and can't be
> used in a terminal, so it isn't exactly a good candidate.

Is `emacs -nw' considered a "terminal"?  (I can never
remember the nuances)  If so then I can use it in a
terminal.  And users with laptops that don't have it
can rebind the command.  I haven't heard a complaint
about it (and I have heard about other keys not OK
for terminals).

But suit yourself.  I use it partly because "insert"
is mnemonic (for the Icicles behavior, which doesn't
just switch to another window).





  reply	other threads:[~2021-04-11 22:33 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-11  1:03 bug#47699: [PATCH] Improve completion-list-mode-map Gregory Heytings
2021-04-11  7:24 ` Eli Zaretskii
2021-04-11  7:31 ` Eli Zaretskii
2021-04-11  7:58   ` Gregory Heytings
2021-04-11  8:14     ` Eli Zaretskii
2021-04-11  8:31       ` Gregory Heytings
2021-04-11  8:34         ` Eli Zaretskii
2021-04-11 10:14           ` Gregory Heytings
2021-04-11 10:40             ` Eli Zaretskii
2021-04-11 10:50               ` Gregory Heytings
2021-04-11 13:31                 ` Eli Zaretskii
2021-04-11 18:30                   ` Gregory Heytings
2021-04-11 18:46                     ` Eli Zaretskii
2021-04-11 19:13                       ` Gregory Heytings
2021-04-11 19:37                         ` Eli Zaretskii
2021-04-11 20:44                           ` Gregory Heytings
2021-04-12  7:24                             ` Gregory Heytings
2021-04-11 18:59                     ` bug#47699: [External] : " Drew Adams
2021-04-11 19:21                       ` Gregory Heytings
2021-04-11 22:33                         ` Drew Adams [this message]
2021-04-12  6:49                           ` Gregory Heytings
2021-04-12 14:50                             ` Drew Adams
2021-05-25  4:39                     ` Lars Ingebrigtsen
2021-05-25  7:32                       ` Gregory Heytings
2021-05-25  7:37                         ` Lars Ingebrigtsen
2021-05-25  8:34                           ` Gregory Heytings
2021-05-25  8:40                             ` Lars Ingebrigtsen
2021-05-25  8:42                               ` Gregory Heytings
2021-05-25 12:31                       ` Basil L. Contovounesios
2021-05-25 19:22                         ` Lars Ingebrigtsen
2021-05-25 19:25                         ` Gregory Heytings
2021-05-25 19:27                           ` Gregory Heytings
2021-04-11 22:36         ` Juri Linkov

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SA2PR10MB4474F57D5514A345FA91366EF3719@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=47699@debbugs.gnu.org \
    --cc=gregory@heytings.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).