Re: The new keymap functions

[Lars Ingebrigtsen <larsi@gnus.org>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So, I've had a look at the chartable stuf -- and...  is the structure of
> a chartable documented anywhere?  Because skimming that file wasn't super
> enlightening.  🤨  But as I guessed, there doesn't seem to be any way to
> remove a chartable entry?  (As opposed to making the entry nil.)

Reading the code helps sometimes, but only if you're reading the correct
code.  The problem is with define-key itself, or rather store_in_keymap:

	    /* Character codes with modifiers
	       are not included in a char-table.
	       All character codes without modifiers are included.  */
	    if (FIXNATP (idx) && !(XFIXNAT (idx) & CHAR_MODIFIER_MASK))
	      {
		Faset (elt, idx,
		       /* nil has a special meaning for char-tables, so
			  we use something else to record an explicitly
			  unbound entry.  */
		       NILP (def) ? Qt : def);
		return def;
	      }
	    else if (CONSP (idx) && CHARACTERP (XCAR (idx)))
	      {
		Fset_char_table_range (elt, idx, NILP (def) ? Qt : def);
		return def;
	      }

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

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no