From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org, Richard Stallman <rms@gnu.org>,
Juri Linkov <juri@linkov.net>
Subject: RE: "whether the global keymap C-x 4 will be replaced by a command,"
Date: Tue, 14 Jul 2020 08:28:41 -0700 (PDT) [thread overview]
Message-ID: <8a09739e-4eaa-49bc-8950-06e130fd5f93@default> (raw)
In-Reply-To: <jwvtuya2m1q.fsf-monnier+emacs@gnu.org>
> >> I don't think we can/should make `C-h k` read all of `C-x 4 C-f`,
> >> indeed. But maybe we could make the following work:
> >> `C-x 4 C-h k C-f`.
> >
> > Farther & farther from Occam - more & more complex.
>
> I don't see what's more or less complex about it.
It's a new exception. And it breaks `C-x 4 C-h'.
And `C-x C-h'? Does that have different behavior
from `C-x 4 C-h' now, or does that too get broken
the same way?
> With other-frame-window `C-x 4` is a (prefix) command.
"With `other-frame-window'". Precisely. That's
apparently the motivation behind this `C-x 4 C-h'
kludge.
A solution looking for a problem engenders the
need for a solution (introducing exceptions) for
a problem it's created. As they say, "Now you've
got two problems...".
> So just like `C-h k C-u` gives you help about the `C-u` binding,
> `C-h k C-x 4` naturally gives you help about the `C-x 4` binding.
`C-u' is an exception, not the rule. It's not
a prefix key: it's not bound to a keymap. It's
bound only to a command. `C-u' - like what you
want to do to `C-x 4' - uses `set-transient-map'.
You want to make `C-x 4' another such exception,
like `C-u', right?
Try `C-h k C-x'. What does that do for you?
`C-h k' has always waited for (expected) a full
key sequence. This is the case in general -
menu, mouse, keyboard, whatever.
(Not to mention that there are 3rd-party help
libraries that let you navigate up, down, and
around the keymap hierarchy, treating prefix
keys the way they are now. Apparently `C-x 4'
will no longer be an ordinary prefix key, i.e.,
bound to a keymap. So that will likely break
such help systems.)
> So if you're interested in the `C-f` binding available after you hit
> `C-x 4`, it's only natural to use `C-x 4 C-h k C-f` (and not only it's
> natural, but it's the only sane option unless we break the `C-h k C-x
> 4` case).
I disagree that it's "only natural". Natural
is as natural does, and it's in the eye of the
beholder or practitioner.
I'd say it's only natural that `C-h k C-x 4 C-f'
does what it does. `C-h k' reads a key sequence
and tells you what it's bound to - what it does.
> > We already have `C-x 4 C-h', which shows you
> > every `C-x 4' key sequence and its command, with
> > a link to its doc. Que demande le peuple ?
>
> You're talking about the current `C-x 4` which is a keymap.
> I'm talking about the case when we've change `C-x 4` to be a prefix
> command, as provided by other-frame-window.
Exactly. I'm questioning that change. I'd
like `C-x 4' to continue to be an ordinary
prefix key, i.e., bound to a keymap, and not
to become something exceptional.
That change offer what, that's worth tossing
the standard, longstanding behavior? Please
answer the questions from the previous mail.
We already have `C-h' following a prefix key,
to give you info about it. `C-h k' is for
info about a complete key sequence.
(And we already have 3rd-party libraries that
let you explore the keymap hierarchy in detail,
and they typically work by handling real prefix
keys, bound to real keymaps.)
next prev parent reply other threads:[~2020-07-14 15:28 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1juSI3-0005ai-6j@fencepost.gnu.org>
[not found] ` <83ft9woo68.fsf@gnu.org>
2020-07-13 2:52 ` "whether the global keymap ‘C-x 4’ will be replaced by a command," Richard Stallman
2020-07-13 23:58 ` "whether the global keymap C-x 4 " Juri Linkov
2020-07-14 4:19 ` Drew Adams
2020-07-14 5:55 ` Stefan Monnier
2020-07-14 14:41 ` Drew Adams
2020-07-14 14:48 ` Stefan Monnier
2020-07-14 15:28 ` Drew Adams [this message]
2020-07-14 15:35 ` John Yates
2020-07-14 14:51 ` Eli Zaretskii
2020-07-14 15:15 ` Stefan Monnier
2020-07-14 16:29 ` Eli Zaretskii
2020-07-15 4:06 ` Stefan Monnier
2020-07-15 14:16 ` Eli Zaretskii
2020-07-15 23:54 ` Juri Linkov
2020-07-16 4:07 ` Stefan Monnier
2020-07-16 22:57 ` Juri Linkov
2020-07-17 2:56 ` Stefan Monnier
2020-07-17 0:56 ` Richard Stallman
2020-07-14 22:27 ` Juri Linkov
2020-07-14 22:55 ` Drew Adams
2020-07-15 4:06 ` Stefan Monnier
2020-07-16 3:21 ` Richard Stallman
2020-07-16 15:05 ` Eli Zaretskii
2020-07-16 23:05 ` Juri Linkov
2020-07-17 2:10 ` Drew Adams
2020-07-18 1:57 ` Richard Stallman
2020-07-18 16:23 ` Sean Whitton
2020-07-18 17:00 ` Drew Adams
2020-07-19 2:28 ` Richard Stallman
2020-07-19 15:28 ` Drew Adams
2020-07-21 0:22 ` Sean Whitton
2020-07-18 1:54 ` Richard Stallman
2020-07-18 23:21 ` Juri Linkov
2020-07-19 0:11 ` Drew Adams
2020-07-19 3:38 ` Stefan Monnier
2020-07-19 22:07 ` Juri Linkov
2020-07-20 3:09 ` Stefan Monnier
2020-07-20 20:50 ` Juri Linkov
2020-07-20 2:39 ` Richard Stallman
2020-07-20 3:13 ` Stefan Monnier
2020-07-15 3:32 ` Richard Stallman
2020-07-19 13:00 ` Barry Fishman
2020-07-19 15:38 ` Drew Adams
2020-07-19 16:20 ` Barry Fishman
2020-07-19 17:45 ` 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
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=8a09739e-4eaa-49bc-8950-06e130fd5f93@default \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=juri@linkov.net \
--cc=monnier@iro.umontreal.ca \
--cc=rms@gnu.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).