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 15:51:04 -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?

> You can check it out here, it also seems reasonable as the potential default
> sort:
> https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/mmm-region.el?h=externals/mmm-mode#n148
>
> If it's not too expensive to use as default, that is.

I was thinking of doing like we did for `overlays-at`, i.e. leave the
default to "unsorted" but add a `sorted` argument.  This also acts as
a reminder that the default is not sorted.

        Stefan

Previous Next

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