bug#25592: Feature request: sorting overlays

[Clément Pit--Claudel]

On 2017-02-03 16:17, Eli Zaretskii wrote:
>> Cc: 25592@debbugs.gnu.org
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> 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.

signature.asc
Description: OpenPGP digital signature