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

[Toby Cubitt <toby@dr-qubit.org>]

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