bug#59067: 29.0.50; Exexpected overlay order in `overlays-in' return value

[Stefan Monnier]

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