From: Jonas Bernoulli <jonas@bernoul.li>
To: Stefan Monnier <monnier@iro.umontreal.ca>,
Robert Pluim <rpluim@gmail.com>
Cc: 62207@debbugs.gnu.org
Subject: bug#62207: 29.0.60; Trying to remove non-existent key binding instead adds a binding
Date: Wed, 15 Mar 2023 23:26:58 +0100 [thread overview]
Message-ID: <87sfe5irbh.fsf@bernoul.li> (raw)
In-Reply-To: <jwvlejx28nl.fsf-monnier+emacs@gnu.org>
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Jonas> As a side-note, it would be nice if it were possible to lookup a
>> Jonas> key in a keymap only, while ignoring bindings in its parent keymap.
>
> Could you explain why you need `keymap-unset-key`
Directional commands usually involve the keys "b", "p", "n" and "f".
These keys are mnemonic but are also scattered all across the keyboard.
So in my own Emacs I have chosen to use "physically-mnemonic" bindings
instead: "i"
"j" "k" "l"
[ Maybe that was a stupid decision. But I made it very early in my
readline/Emacs career. There is no way back. ]
That makes it necessary to edit many keymaps. Using keymap-unser with
non-nil REMOVE makes that much less painful. It's still painful but any
relieve is welcome.
In magit-section-mode-map, for example, I make these changes
default custom
"p" replaced by "i" magit-section-backward
"n" replaced by "k" magit-section-forward
magit-mode-map has the above keymap as parent. It also binds "i"
to magit-gitignore. I could just override that binding using
(keymap-set magit-mode-map "i" #'magit-section-backward)
but it is much clean to
(keymap-unset magit-mode-map "i" t)
It is also more future-proof. Imagine the author of Magit decides
that magit-section-{forward,backward}-sibling are actually more
important than magit-section-{forward,backward}, and thus exchanges
the respective key bindings.
If I previously removed the conflicting binding in magit-mode-map,
my bindings continue to be consistent; "i"/"k" continue to do the
inverse of one another. But if I was forced to explicitly double
down on bindings in derived keymaps, then that would be less robust.
In this case I would end up with this in magit-mode-map:
"i" magit-section-backward
"k" magit-section-forward-sibling
> lookup "all but the ignore the parent"?
kmu-lookup-local-key
In KEYMAP, look up key sequence KEY. Return the definition.
Unlike `keymap-lookup' (which see) this doesn't consider bindings
made in KEYMAP's parent keymap.
A long time ago I tried to automate the process of moving directional
commands to different keys. When mapping through bindings of a keymap
in order to do that, it was important to ignore bindings made in the
parent keymap. So I used a variant of map-keymap that did that, and it
made sense to implement a variant of lookup-key along the same line. I
have not used these functions in a major way since I stopped trying to
automate the remapping.
But they just came in handy. When using keymap-unset to remove a
binding but there isn't actually a binding, then that ends up adding
a binding. To work around that bug I have to first check if there is
a binding. But it must be a binding in the keymap itself, not a parent
keymap.
> I'm curious because the meaning of these can be subtly more complex than
> meets the eye once you consider things like `make-compose-keymap`.
My current implementation seems to treat later keymaps in composed
keymaps like parent keymaps. Maybe that makes sense, maybe a proper
implementation should make a distinctions between parent keymaps and
"tail" keymaps.
>> A feature request and a bug report? Tsk ;-) Luckily the infrastructure
>> is actually there already.
I had a hunch the two might require changes in the same part of the
code. ;D
> Hmm... if you need to add yet-another-arg to `Flookup_key`, than I'm not
> sure it qualifies as "the infrastructure is actually there already."
What I care about the most is that the bug is fixed (instead of users
being told to not use the REMOVE argument, as you seem to suggest
elsewhere in this thread).
Key lookup that ignores parent keymaps would be nice, but not nearly as
important as the bugfix.
> BTW, `map-keymap-internal` could be another way to attack the problem
> (it has other downsides, but it stops before entering the parents).
>
>
> Stefan
next prev parent reply other threads:[~2023-03-15 22:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-15 16:07 bug#62207: 29.0.60; Trying to remove non-existent key binding instead adds a binding Jonas Bernoulli
2023-03-15 16:51 ` Jonas Bernoulli
2023-03-15 17:36 ` Robert Pluim
2023-03-15 18:12 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-15 22:26 ` Jonas Bernoulli [this message]
2023-03-17 21:09 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-20 18:46 ` Jonas Bernoulli
2023-03-20 21:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-15 17:13 ` Eli Zaretskii
2023-03-15 17:39 ` Robert Pluim
2023-03-15 18:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-17 8:23 ` Eli Zaretskii
2023-03-17 8:54 ` Robert Pluim
2023-03-17 9:55 ` Robert Pluim
2023-03-17 11:36 ` Eli Zaretskii
2023-03-17 13:20 ` Robert Pluim
2023-03-17 11:32 ` Eli Zaretskii
2023-03-17 13:20 ` Robert Pluim
2023-03-20 18:14 ` Jonas Bernoulli
2023-03-17 20:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-18 5:51 ` Eli Zaretskii
2023-03-18 14:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-18 9:43 ` Robert Pluim
2023-03-18 14:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-20 9:09 ` Robert Pluim
2023-03-20 12:17 ` Eli Zaretskii
2023-03-20 15:03 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-20 15:27 ` Robert Pluim
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=87sfe5irbh.fsf@bernoul.li \
--to=jonas@bernoul.li \
--cc=62207@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=rpluim@gmail.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 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).