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

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 19 Jul 2021 17:26:11 +0200
> Cc: 459@debbugs.gnu.org
> 
> > 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.

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.