Subject: bug#25592: Feature request: sorting overlays

From: Clément Pit--Claudel <[email-masked]>
Date: Fri, 3 Feb 2017 16:51:24 -0500

On 2017-02-03 16:17, Eli Zaretskii wrote:
>> Cc: [email-masked]
>> From: Clément Pit--Claudel <[email-masked]>
>> Date: Fri, 3 Feb 2017 10:19:15 -0500
>>
>>>> I'm writing a function that copies overlay properties to text properties.
>>>
>>> That function probably converts overlays by traversing buffer
>>> positions from beginning to end, no?  Then overlays-at should be what
>>> you need, and next-overlay-change is your friend to move to the next
>>> "interesting" position when you are done with this one.
>>>
>>> Isn't that what you are doing?
>>
>> No: I'm iterating over all overlays, and applying them one by one.
> 
> Why not do it as I suggest?  Then your problems with sorting will be
> solved as a nice side-effect.

I'm worried about the cost and the additional implementation complexity.  My current algorithm is very simple: iterate over overlays, applying their properties to the ranges they cover.  In contrast, scanning over overlays introduces additional complexity (I need to keep track of which overlays I have already applied and move around the buffer), and additional costs (next-overlay-change seems to do quite a bit of work).

None of this is a show stopper (in fact, I don't even know for sure that the slowdown would be significant, and I do know that I don't expect to have that many overlays anyway :), but it'd be nice to be able to use the "simpler" solution.

>>>> I reimplemented compare_overlays in ELisp, but that seems brittle.
>>>
>>> How did you implement in Lisp the "last resort" of comparison, which
>>> compares addresses of the C structs?
>>
>> I didn't :)
> 
> So it isn't really a solution ;-)

It's not a full reimplementation, but it's enough of a solution for me :) The docs say “If SORTED is non-‘nil’, the list is in decreasing order of priority”, and that's what my implementation does.

Cheers,
Clément.