unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.)



  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).