Re: Making a key undefined again

[Jonas Bernoulli]

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