[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making a key undefined again

From: Stefan Monnier
Subject: Re: Making a key undefined again
Date: Mon, 25 Oct 2021 19:10:44 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

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

Ah, I see, that makes more sense.

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

Actually, it's not guaranteed.  Try it with:

    (let ((parent (make-sparse-keymap))
          (child (make-keymap)))
      (set-keymap-parent child parent)
      (define-key parent [?a] nil)
      (define-key child  [?a] 'bar)


>> 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:

[ Now that I see the correction to your code, I understand better what
  you mean by "not bound at all".  ]

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

How common is this case?

So your notion of "no binding at all" can also be described as something
like "use the binding of the parent".


reply via email to

[Prev in Thread] Current Thread [Next in Thread]