GNU bug report logs - #62207
29.0.60; Trying to remove non-existent key binding instead adds a binding

Previous Next

Full log

View this message in rfc822 format

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Robert Pluim <rpluim <at> gmail.com>
Cc: 62207 <at> 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

Stefan Monnier <monnier <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.