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

[Dmitry Gutov]

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