GNU bug report logs - #59067
29.0.50; Exexpected overlay order in `overlays-in' return value

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 59067 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#59067: 29.0.50; Exexpected overlay order in `overlays-in' return value
Date: Fri, 11 Nov 2022 04:13:03 +0200

On 10.11.2022 23:56, Stefan Monnier wrote:
> I'm not asking for any kind of justification, but I'm wondering what
> would happen if you used a different sort order (i.e. the same but in
> reverse, or sorted by overlays's end, ...): would the rest of the code
> need to be adjusted?  If so, in a trivial way?  Or does some of the
> algorithm rely crucially on this particular ordering?

Most of the code there needs to use the "innermost" overlay, and more or 
less ignore the rest of them.

If the return value was in reverse, I think the adjustment would be to 
call 'reverse', or sort it all over again, rather than calling (car 
(last overlays)) every time.

Another place which might be important is the order in which the 'face' 
property is applied by Emacs (with 'priority' being equal).

Previous Next

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