[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#459: Zero-length overlays, overlay keymaps, and `overlays-at'
From: |
Toby Cubitt |
Subject: |
bug#459: Zero-length overlays, overlay keymaps, and `overlays-at' |
Date: |
Tue, 20 Jul 2021 13:34:39 +0000 |
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
- bug#459: Zero-length overlays, overlay keymaps, and `overlays-at', Lars Ingebrigtsen, 2021/07/19
- bug#459: Zero-length overlays, overlay keymaps, and `overlays-at', Eli Zaretskii, 2021/07/19
- bug#459: Zero-length overlays, overlay keymaps, and `overlays-at', Lars Ingebrigtsen, 2021/07/19
- bug#459: Zero-length overlays, overlay keymaps, and `overlays-at', Eli Zaretskii, 2021/07/19
- bug#459: Zero-length overlays, overlay keymaps, and `overlays-at', Stefan Monnier, 2021/07/19
- bug#459: Zero-length overlays, overlay keymaps, and `overlays-at', Lars Ingebrigtsen, 2021/07/19
- bug#459: Zero-length overlays, overlay keymaps, and `overlays-at', Eli Zaretskii, 2021/07/19
- bug#459: Zero-length overlays, overlay keymaps, and `overlays-at', Lars Ingebrigtsen, 2021/07/20
- bug#459: Zero-length overlays, overlay keymaps, and `overlays-at', Eli Zaretskii, 2021/07/20