GNU bug report logs - #25592
Feature request: sorting overlays

Previous Next

Package: emacs;

Reported by: Clément Pit--Claudel <clement.pitclaudel <at> live.com>

Date: Tue, 31 Jan 2017 20:33:02 UTC

Severity: wishlist

Done: Clément Pit--Claudel <clement.pitclaudel <at> live.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25592 <at> debbugs.gnu.org
Subject: bug#25592: Feature request: sorting overlays
Date: Fri, 3 Feb 2017 16:51:24 -0500
[Message part 1 (text/plain, inline)]
On 2017-02-03 16:17, Eli Zaretskii wrote:
>> Cc: 25592 <at> debbugs.gnu.org
>> From: Clément Pit--Claudel <clement.pitclaudel <at> 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 (application/pgp-signature, attachment)]

This bug report was last modified 8 years and 104 days ago.

Previous Next


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