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: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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 23:00:51 +0200

On 10.11.2022 22:51, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
>>> 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.

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

Yeah, ok.

Previous Next

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