Re: The new keymap functions

[Stefan Monnier]

> If you give a definition of nil, then it stores t, so you can never
> actually get back the inheritance.  (If it's nil, then it looks it up in
> the parent map.)

That's right.  For chartables (and arrays), a nil entry *is* the absence
of a binding (rather than an explicit binding to nil), so instead we use
`t` there to mean an explicit binding to nil.

> We presumably want to keep doing this for backwards compatibility, so I
> guess adding a new optional parameter to `define-key' to really set it
> to nil if requested is the way to go?  (And the same in the sparse-map
> case.)

That's right: the best way to write a "remove key-binding" function is
most likely to make `define-key` accept a special
`:internal-remove-binding` value for the binding: for char-tables and
arrays you can just make it store a nil in the table, and for cons
cells, it should remove the cons-cell (which will probably require more
changes to the code, tho maybe you can get away with calling `delq` to
remove the cons cell rather than having to remember the previous
cons-cell so your can `setcdr` it).

If we could go back in time, we'd use nil for `:internal-remove-binding`
and `t` for "hide parent bindings" ;-)


        Stefan