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: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dgutov <at> yandex.ru>
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: Thu, 10 Nov 2022 21:32:11 -0500

>> 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.

Hmm... but we're talking about `overlays-in`, so many/most overlays
might be completely disjoint and thus incomparable in the sense of
which one is "innermost".

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

Same here: this is designed for the case where all of those overlays
cover a given position, so they're not disjoint.  This said, sorting
using that same algorithm for disjoint overlays would end up sorting by
overlay-start, if I read the code correctly, so it might not be
a bad choice.


        Stefan

Previous Next

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