From: Drew Adams <drew.adams@oracle.com>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, 14086@debbugs.gnu.org
Subject: bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"
Date: Sat, 3 Oct 2020 22:00:39 -0700 (PDT) [thread overview]
Message-ID: <a82a5524-f955-47c2-a21e-8832a642ebb9@default> (raw)
In-Reply-To: <87k0w690gg.fsf@web.de>
> > Not sure what you're saying. Why should we show the
> > shadowed binding? That's the question I was asking
> > there. How it comes to be shown was the subject
> > above that in the post. But should it be shown?
> > If so, why?
>
> It's debatable, sure. But sometimes it's useful info, don't you think?
> If you unbind the shadowing key to nil, the other binding will take
> effect, so in that sense it is meaningful to the behavior of the keymap.
>
> Do you think we should not list shadowed bindings (and why)?
No, I was just asking the question - open.
You provided a reason to show shadowed bindings.
That's good enough for me - makes sense.
But it only makes sense if someone can understand.
What's missing is something, somewhere, that tells
you what it means to show one binding for a key
with no special mention (no mention of shadowing)
and another binding for the same key, with just a
mention that it is shadowed by some other key.
What shadowing means needs to be conveyed somehow,
somewhere. And it would be better to list the
command that shadows the shadowed command/binding.
As an analogy, if some function or variable is an
alias for another, the help tells you that. Or if
you ask for the value of a variable in a buffer
where it's local, the help tells you the local
value and lets you know what the global value is.
If we list an `M-r' binding to
`previous-matching-history-element' that's shadowed
by an `M-r' binding to `icicle-roundup' then it
would be good to say that the former is shadowed by
the latter. Currently we say only that it is
shadowed by another "mode".
It would be even better if we said what keymap
the shadowed binding is bound in, and what keymap
the shadowing binding is bound in. Dunno whether
that's always possible, but it would help.
The first thing that's missing is what "shadow"
means - that wasn't clear to me at all. I think
it would help, even if we didn't explain that
term, if we explicitly said which binding (e.g.
`icicle-roundup') does the shadowing. With that
info a user might be able to guess what "shadow"
means.
What's most important is that it's clear to a user
that ONLY the shadowing binding is in effect.
Mentioning the shadowed binding is only extra info
about what could happen if the shadowing binding
weren't in effect. (Like what would happen if a
buffer-local value were removed.)
Another thing that hampers understanding is the
order of the bindings listed. Both bindings of
`M-r' should be listed next to each other.
I'm looking at the output of `describe-keymap'
for `minibuffer-local-completion-map', and the
order is not clear/useful, I think.
[I see the same thing using either my version of
`describe-keymap' or the version added to Emacs 28
(bug #30660).]
But #14086 is about the unclear help when it comes
to listing shadowed bindings. I agree that it can
be useful to list such bindings, but only if we
can make clear what they mean. The gain is minor,
and not worth it if we can't make this clear, I
think.
next prev parent reply other threads:[~2020-10-04 5:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-29 6:04 bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)" Drew Adams
2014-02-10 4:40 ` Lars Ingebrigtsen
2016-04-28 22:49 ` Lars Ingebrigtsen
2016-04-29 11:49 ` Michael Heerdegen
2016-04-29 12:26 ` Lars Ingebrigtsen
2016-04-29 12:42 ` Eli Zaretskii
[not found] ` <<83h9ekwpqj.fsf@gnu.org>
2016-04-29 16:26 ` Drew Adams
2016-04-29 16:29 ` Lars Ingebrigtsen
2020-08-25 11:15 ` Lars Ingebrigtsen
2020-10-03 22:09 ` Michael Heerdegen
2020-10-04 13:58 ` Lars Ingebrigtsen
2020-10-04 17:40 ` Drew Adams
2020-10-04 18:25 ` Eli Zaretskii
2020-10-04 19:13 ` Drew Adams
2020-10-04 23:45 ` Michael Heerdegen
2020-10-05 16:40 ` Drew Adams
2020-10-05 22:33 ` Michael Heerdegen
2020-10-05 23:37 ` Drew Adams
2020-10-05 4:45 ` Eli Zaretskii
2020-10-03 22:48 ` Drew Adams
2020-10-04 1:44 ` Michael Heerdegen
2020-10-04 2:09 ` Drew Adams
2020-10-04 2:41 ` Michael Heerdegen
2020-10-04 5:00 ` Drew Adams [this message]
2020-10-06 21:20 ` Michael Heerdegen
2020-10-06 22:54 ` Drew Adams
2020-10-07 7:22 ` Eli Zaretskii
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=a82a5524-f955-47c2-a21e-8832a642ebb9@default \
--to=drew.adams@oracle.com \
--cc=14086@debbugs.gnu.org \
--cc=larsi@gnus.org \
--cc=michael_heerdegen@web.de \
/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).