Re: Making a key undefined again

[Jonas Bernoulli]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

That can be fixed too.  How does one determine if an event is / would be
stored in a keymap's char-table?  So far I have:

  (and (char-table-p (cadr MAP))
       (ignore-errors (char-table-range (cadr MAP) EVENT) t))

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

When implementing an alternative set of key bindings across all of Emacs
that diverge from the "standard Emacs key bindings" a lot (up to the
scale of Vim but possibly not quite *that* drastically different), then
it might be needed for essentially every keymap.

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

Yes. (Or the default binding, or ...)

remove(add(MAP KEY) KEY) == MAP