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

[Stefan Monnier]

Lars Ingebrigtsen [2021-07-19 18:37:07] wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>>> > 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).
>
> [...]
>
>> We could add a new optional argument to overlays-at, to make it return
>> such overlays.  That would avoid the risk of breaking unsuspecting
>> callers.
>
> Yeah, that's true.  Do you have any opinion on whether a) or b) would
> make the most sense if given this optional argument?  I'm leaning
> towards b)...

I vote for a) with or without the requirement of a new optional arg.
The reason I vote for a) rather than b) is because AFAICT `overlays-at`
does not pay currently attention to from/rear advance properties, so it
would be weird to do that just for empty overlays.


        Stefan