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

Previous Next

Full log

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

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: Re: bug#59067: 29.0.50; Exexpected overlay order in `overlays-in'
 return value
Date: Thu, 10 Nov 2022 16:56:15 -0500

>>>> Maybe Someone™ should browse through the various calls to `overlays-in`
>>>> out there to try and see which orderings could be useful.
>>> FWIW, mmm-mode uses overlay sorting based on the value of overlay-start
>>> (first come overlays where this value is higher, so basically the more
>>> deeply nested ones, if we imagine all overlays to be strictly nested, as is
>>> the case with mmm-mode).
>> AFAICT it sorts first based on priority and only for equal-priority
>> overlays does it use the overlay's start.
>> Is there any specific reason for this particular ordering?
>
> Historical, I suppose. mmm-mode doesn't set the 'priority' property these
> days (the little snippet of code doing that is commented out).
>
> It kind of makes sense, but I don't have a better argument than that.

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?

In many cases, I have found that the ordering doesn't really matter,
as long as it's deterministic.


        Stefan

Previous Next

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