Re: Making a key undefined again

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

:-(

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


        Stefan