[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
From: |
Lars Ingebrigtsen |
Subject: |
bug#11840: 24.1.50; nil keymap element on high priority overlay should fallthrough to low priority overlay |
Date: |
Tue, 07 Sep 2021 19:36:33 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Christopher Monsanto <chris@monsan.to> writes:
> 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!
>
> Try this:
>
> (setq m (make-sparse-keymap))
> (define-key m "k" '(lambda nil (interactive) (message "overlay 1")))
>
> (setq m2 (make-sparse-keymap))
> (define-key m2 "k" nil)
>
> (let ((o (make-overlay 0 5))
> (o2 (make-overlay 0 5)))
> (overlay-put o 'keymap m)
> (overlay-put o 'priority 100)
> (overlay-put o2 'keymap m2)
> (overlay-put o2 'priority 9999)
> (delete-overlay o2))
>
> eval-buffer again, and k self inserts. If we never create the second
> overlay, it prints the msg.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
I'm unable to reproduce this in Emacs 28 -- if I hit `k', I get the
message (as expected). Are you still seeing this issue in recent Emacs
versions?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#11840: 24.1.50; nil keymap element on high priority overlay should fallthrough to low priority overlay,
Lars Ingebrigtsen <=