[Top][All Lists]

[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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]