[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11840: 24.1.50; nil keymap element on high priority overlay should f
bug#11840: 24.1.50; nil keymap element on high priority overlay should fallthrough to low priority overlay
Mon, 02 Jul 2012 14:21:12 -0400
Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)
>>> One more symptom, and I doubt this could be anything but a bug: if you
>>> delete the high priority overlay, we *still* don't use the lower
>>> priority overlay's keymap!
>> This is a limitation of the way properties are "merged".
>> More specifically, in most cases properties coming from different
>> overlays (and from text-properties) are *not* merged. Instead, the
>> property of the highest-priority overlay is used.
> For the problem you cited, that seems to be irrelevant...
Indeed, thank you for correcting me: for the cited problem, the issue is
most likely that Emacs reads the set of active keymaps when it starts
waiting for a key-sequence, rather than when it actually sees
a key-press, so if you remove overlays via things like process-filters,
the set of keymaps used for the key-lookup may not reflect the set of
keymaps that were actually present when the key was pressed.
This one is indeed a (known) bug, rather than a limitation.
Fixing it might not be too hard, but the culprit is in read_key_sequence
which is a dreadfully intimidating function.