[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The new keymap functions
From: |
Lars Ingebrigtsen |
Subject: |
Re: The new keymap functions |
Date: |
Sun, 14 Nov 2021 05:56:31 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
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
- Re: The new keymap functions, (continued)
Re: The new keymap functions, Richard Stallman, 2021/11/14
Re: The new keymap functions, xenodasein, 2021/11/13
Re: The new keymap functions, xenodasein, 2021/11/14