bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#459: Zero-length overlays, overlay keymaps, and `overlays-at'


From: Lars Ingebrigtsen
Subject: bug#459: Zero-length overlays, overlay keymaps, and `overlays-at'
Date: Wed, 21 Jul 2021 12:36:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Toby Cubitt <toby@dr-qubit.org> writes:

> I suppose if it was documented, I might have remembered that it was
> already fixed :) Maybe it is somewhere, but I missed it? The Emacs
> Lisp manual currently (Emacs stable) has this to say on the overlay
> keymap property:
>
> "This keymap is used when the character after point is within the overlay"
>
> Which is technically incorrect since that NEWS.22 item, as it doesn't
> cover zero-length, null front-advance, non-null rear-advance
> overlays. A concise, technically correct wording that I think covers
> all cases would be:
>
> "This keymap is used when a character inserted after point would be
> included within the overlay"
>
> But maybe it would be better to be less concise, and spell out the
> zero-length overlay special case separately.

It's not just zero-length overlays -- any overlay with rear-advance has
this keymap effect on the character after the end of the overlay.  And
in addition, zero-length overlays have to have front-advance nil for
this to happen.  :-/

I've now mentioned that these properties have an effect in the overlay
keymap item, but punted to the "Managing Overlays" section to actually
explain how these overlays behave, because it's too complicated to
repeat in that item.

-- 
(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]