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

[Toby Cubitt]

On Tue, Jul 20, 2021 at 02:50:20PM +0300, Eli Zaretskii wrote:
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: 459@debbugs.gnu.org,  monnier@iro.umontreal.ca,  
> > t.s.cubitt.98@cantab.net
> > Date: Tue, 20 Jul 2021 13:28:10 +0200
> >
> > However...  after implementing this, I see that `overlays-in' is
> > something that exists?  And does include zero-length overlays?  *sigh*
> > So `(overlays-in 1 1)' is the answer to this bug report.
>
> Oops.  For some reason, I was under the impression that the OP tried
> overlays-in as well.  I now see that I've just imagined that.  Sorry.

The OP on this was so much younger when he submitted the bug report, he might 
as well have been a different person :)

At this length of time, I can't remember for sure. But it looks like I used 
overlays-in as a workaround in the auto-overlays package (where this bug report 
originated). So I guess I did try it. In which case, apologies from my 
15-years-ago self for not noting this in the bug report. Maybe the bug report 
was more about the API doing something inconsistent and surprising, which 
looked like a bug rather than deliberate?

Still seems surprising to me that overlays-at won't return all overlays "at" 
point, but overlays-in will return overlays that technically aren't "in" the 
specified region. (The emptyset canonically contains no elements.) I wonder if 
the proposed change to overlays-at would really break anything? Seems like a 
case where adding an optional argument or some such, deprecating the current 
default behaviour, issuing a warning for x decades, then making the change to 
overlays-in, would clean up the API here.

But I bow to your judgement on the cost-benefit of backwards-compatibility 
versus API ugliness.

I do remember that the first half of this bug report, about the interacting 
between overlay keymaps and zero-length overlays, was more significant. I 
included the overlays-at part of the bug report, as I thought it might be 
related (as I wrote back then). The fact that keymap properties of zero-length 
overlays do not apply, irrespective of the front/read-advance properties, means 
it's impossible to bind a key at a single point location in Emacs. It required 
an ugly kludge to work around this in the auto-overlays package.

This first bug in the report still seems to be there in current stable Emacs. 
Is the intention to dismiss that first bug as "won't fix", too? Just flagging, 
in case that part got missed.

Best wishes,
Toby
--
Dr T. S. Cubitt
Reader (Associate Professor) in Quantum Information
Royal Society University Research Fellow
Department of Computer Science
University College London

email: tsc25@cantab.net
web:   www.dr-qubit.org