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