bug#11840: 24.1.50; nil keymap element on high priority overlay should fallthrough to low priority overlay

[Stefan Monnier]

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


        Stefan