Re: keymap inheritance for non-sparse keymaps

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/emacs/address@hidden> writes:
> 
> |> It should be an object that is never used as a binding.
> |> I.e. there should be no code ever that does
> |> 
> |>    (define-key map key <object>)
> |> 
> |> Kim's suggestion of simply using t might be good.
> |> But we have to be sure that no code uses (define-key map key t).
> 
> Since a keymap entry of t didn't have a defined meaning before (t is not
> a function) it should be harmless to give it a new meaning.

I would rather not advertise it, tho.  Because the behavior of that
new value should be pretty much the same as nil currently (which
is to hide a parent binding but not a binding in a map of lower
priority).  That behavior doesn't quite come for free, so instead
of checking for nil, we'd now have to check for nil and t, which
is not unbearable, but annoying.

If we don't advertise it, we can keep it as an internal detail
(after all, the representation of keymaps should not be relied upon,
and can't be relied upon in XEmacs) so the added test only occurs at
the two places where it is needed (i.e. for char tables).


        Stefan