[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making a key undefined again
From: |
Jonas Bernoulli |
Subject: |
Re: Making a key undefined again |
Date: |
Tue, 26 Oct 2021 00:49:34 +0200 |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> (defun kmu-remove-key (keymap key)
> [...]
>> (if (= (length key) 1)
>> (delete key keymap)
That's a bug (thanks for the report), it should be:
(cl-delete key keymap :count 1)
There always is a (EVENT) entry in the keymap itself because of this line
further up:
(define-key keymap key nil)
(At which point KEY still has the form [EVENT], not (EVENT).)
> Also, AFAIK the only difference between a nil binding and "no binding at
> all" is whether it can hide bindings from the parent, but if you also remove
> the binding from the parent, then you end up with the same result as a nil
> binding, no?
This would only have happened (before the bugfix) in a situation like
(keymap
(97 . undesired)
keymap
(97))
>> Maybe the code could be simplified; it has been a long time since
>> I wrote that, with a little help from my friends. But I hope the
>> doc-string makes it clear why something like this is desirable.
>
> Actually, it didn't make it clear for me. I hope I understand the
> differences between an `undefined` binding, a `nil ` binding, and no
> binding at all, but I don't know why unsetting a key is important and
> even less when unsetting it by making it have no binding at all
> is necessary.
Say special-mode `foo-mode' does:
(define-key foo-mode-map "n" 'foo-next-thing)
And derived mode `foobar-mode' does:
(set-keymap-parent foobar-mode-map foo-mode-map)
(define-key foobar-mode-map "n" 'foobar-next-thing-except-if-boring)
But I like plain old `foo-next-thing' better.
If I do
(define-key foobar-mode-map "n" nil)
then that doesn't bring back `foo-next-thing'. Instead "n" invokes
`self-insert-command' from `global-map'.
I could do
(define-key foobar-mode-map "n" 'foo-next-thing)
but that breaks when `foo-next-thing' is renamed to `foo-forward'.
And even if that never happens, it still complicates `foobar-mode-map',
which now has a binding for `foo-next-thing', which isn't actually
necessary because an identical binding exists in the parent keymap
`foo-mode-map'.
Jonas
- Re: Moving kbd to subr.el, (continued)
- Re: Moving kbd to subr.el, Juri Linkov, 2021/10/19
- Making a key undefined again, Jonas Bernoulli, 2021/10/25
- RE: [External] : Making a key undefined again, Drew Adams, 2021/10/25
- Re: Making a key undefined again, Lars Ingebrigtsen, 2021/10/25
- Re: Making a key undefined again, Stefan Monnier, 2021/10/25
- Re: Making a key undefined again, Gregory Heytings, 2021/10/25
- Re: Making a key undefined again,
Jonas Bernoulli <=
- Re: Making a key undefined again, Jonas Bernoulli, 2021/10/25
- Re: Making a key undefined again, Stefan Monnier, 2021/10/25
- Re: Making a key undefined again, Gregory Heytings, 2021/10/25
- Re: Making a key undefined again, Jonas Bernoulli, 2021/10/26
- Re: Making a key undefined again, Stefan Monnier, 2021/10/26
- Re: Moving kbd to subr.el, Juri Linkov, 2021/10/18
- Re: Moving kbd to subr.el, Gregory Heytings, 2021/10/18
- Re: Moving kbd to subr.el, Lars Ingebrigtsen, 2021/10/18
- Re: Moving kbd to subr.el, T.V Raman, 2021/10/17
- Re: Moving kbd to subr.el, Eli Zaretskii, 2021/10/18