[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making a key undefined again

From: Gregory Heytings
Subject: Re: Making a key undefined again
Date: Mon, 25 Oct 2021 23:27:11 +0000

but that breaks when `foo-next-thing' is renamed to `foo-forward'. And even if that never happens, it still complicates `foobar-mode-map', which now has a binding for `foo-next-thing', which isn't actually necessary because an identical binding exists in the parent keymap `foo-mode-map'.

How common is this case?

So your notion of "no binding at all" can also be described as something like "use the binding of the parent".

This happens because t is stored in the keymap when using (define-key ... nil), as explained in store_in_keymap():

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

Would it not be possible to add another value that would actually be be stored as a nil at that point, for example 'nil / QQnil?

reply via email to

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