bug#25592: Feature request: sorting overlays

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 25592@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sun, 5 Feb 2017 11:21:04 -0500
> 
> > Why would you need to keep track of overlays, if you always process 
> > each one just once?
> 
> To avoid applying the same overlay twice. But I think I understand your suggestion better now, and you meant that I would apply each overlay's properties not to the entire overlay's range (overlay-start .. overlay-end), but instead just to the current range (as determined by next-overlay-change).  Correct?

Yes, of course.  That's how the display engine handles overlays.

> > But the "simpler" solution has a problem, whereby the order of the 
> > overlays might depend on buffer position for which you evaluate the 
> > order, because overlays could begin at the same position, but end at 
> > different ones, or vice versa.  IOW, the overlaps between portions
> > of the buffer text "covered" by different overlays could be partial.
> > How do you handle this situation in your algorithm?  The correct
> > solution would require having different values of the corresponding
> > text property for different locations, according to the
> > highest-priority overlay at each location.  Am I missing something?
> 
> I think I'm probably the one missing something :) I'm not sure I understand the problem.  Here's my current algorithm:
> [...]
> (defun esh--commit-overlays (buf)
>   "Copy overlays of BUF into current buffer's text properties."
>   (let ((pt-min-diff (- (with-current-buffer buf (point-min)) (point-min))))
>     (dolist (ov (esh--buffer-overlays buf))
>       (let* ((start (max (point-min) (- (overlay-start ov) pt-min-diff)))
>              (end (min (point-max) (- (overlay-end ov) pt-min-diff)))
>              (ov-props (overlay-properties ov))
>              (cat-props (let ((symbol (plist-get ov-props 'category)))
>                           (and symbol (symbol-plist symbol))))
>              (face (let ((mem (plist-member ov-props 'face)))
>                      (if mem (cadr mem) (plist-get cat-props 'face))))
>              (props (esh--filter-plist (append cat-props ov-props)
>                                     (cons 'face esh--overlay-specific-props))))
>         (when face
>           (font-lock-prepend-text-property start end 'face face))
>         (add-text-properties start end props)))))

What will happen if you have 2 overlays like this:

               +------------- OV2 -------+
   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   +------- OV1 ---------+

and OV2 has a higher priority than OV1?

> >>>>> 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.
> > 
> > Then there will be use cases where your solution will give a wrong 
> > value to the text property that replaces the overlays.
> 
> Snap.  Do you have a concrete example?  I imagine this would happen if two overlays are added to the same range of text, with no explicit priority?

Or with explicitly equal priority.