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: Mon, 19 Jul 2021 17:26:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Toby Cubitt <t.s.cubitt.98@cantab.net> writes:

> "Bug" description:
> ------------------
> `overlays-at' never returns zero-length overlays.
>
> Steps to reproduce:
> -------------------
> (make-overlay 1 1)  ; any position will do
> (overlays-at 1)
>
> Returns nil instead of the overlay from 1 to 1.

(I'm going through old bug reports that unfortunately wasn't resolved at
the time.)

This is still the case in Emacs 28.

> Impact:
> -------
> Again, zero-length overlays are probably rarely used. But this makes
> it impossible in Emacs to find a zero-length overlay using
> `overlays-at'. Instead, one has to work-around this using three calls
> to `overlays-in' then filter out overlays that shouldn't be in the
> list.

Or just `overlay-lists'.

> Overlays do fairly frequently become zero-length when the text they
> cover is deleted (depending on their front- and rear-advance
> properties), and this "bug" makes them suddenly disappear from the
> return value of `overlays-at' even though they still exist in the
> buffer.
>
> Suggestions for possible fixes:
> -------------------------------
> a) Modify (overlays-at pos) to return zero-length overlays that start
> at pos (it already returns all other overlays that start at
> pos). Again, this seems unlikely to have significant impact on other
> parts of Emacs, since zero-length overlays are rarely used.
>
> b) Modify (overlays-at pos) to return zero-length overlays that start
> at pos, and have a null front-advance and non-nil rear-advance
> property. (The logic for this is the same as in option b) for the
> overlay keymaps issue.)
>
> c) Leave `overlays-at' unchanged, and define a new function
> `overlays-at-point' that implements either a) or b).

Hm...  the issue here is that if a zero-length overlay has a
read-advance property, then it can influence what happens when you type
something at that position.  So b) makes sense to me on that level.

But I'd worry that it'd break code that's not aware of zero-length
overlays.  And introducing a new function doesn't seem very attractive.

Does anybody have any opinions here?

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