GNU bug report logs - #459
Zero-length overlays, overlay keymaps, and `overlays-at'

Previous Next

Full log

Message #25 received at 459 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 459 <at> debbugs.gnu.org, t.s.cubitt.98 <at> cantab.net
Subject: Re: bug#459: Zero-length overlays, overlay keymaps, and `overlays-at'
Date: Mon, 19 Jul 2021 19:29:05 +0300

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.