bug#25592: Feature request: sorting overlays

bug#25592: Feature request: sorting overlays

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 327 bytes --]

Hi,

Is there a way to get a list of all overlays in a buffer, sorted by priority?
Currently only overlays-at seems to have a sorted parameter, and the sorting is done in C (so there seems to be no way on the list side to sort the results of overlays-in, except for reimplementing compare_overlays).

Thanks!
Clément


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25592: Feature request: sorting overlays

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Tue, 31 Jan 2017 15:32:26 -0500
> 
> Is there a way to get a list of all overlays in a buffer, sorted by priority?

I'm not sure I understand the request.  Do you mean that the result of
this would be a list of overlays, where the first one is the overlay
of the highest priority _anywhere_ in the buffer, the next one of the
2nd highest priority, possibly in an entirely different place in the
buffer, and so on -- i.e. completely disregarding the overlay
positions?  That's a very strange order.  Which job(s) need(s) such an
order, and why?

bug#25592: Feature request: sorting overlays

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 888 bytes --]

On 2017-02-01 08:01, Eli Zaretskii wrote:
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> Date: Tue, 31 Jan 2017 15:32:26 -0500
>>
>> Is there a way to get a list of all overlays in a buffer, sorted by priority?
> 
> I'm not sure I understand the request.  Do you mean that the result of
> this would be a list of overlays, where the first one is the overlay
> of the highest priority _anywhere_ in the buffer, the next one of the
> 2nd highest priority, possibly in an entirely different place in the
> buffer, and so on -- i.e. completely disregarding the overlay
> positions? 

Yup, that's what I mean.

> That's a very strange order.  Which job(s) need(s) such an
> order, and why?

I'm writing a function that copies overlay properties to text properties.  I reimplemented compare_overlays in ELisp, but that seems brittle.

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25592: Feature request: sorting overlays

[Eli Zaretskii]

> Cc: 25592@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Thu, 2 Feb 2017 14:41:21 -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?

> 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?

bug#25592: Feature request: sorting overlays

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 845 bytes --]

On 2017-02-02 15:43, Eli Zaretskii wrote:
>> Cc: 25592@debbugs.gnu.org
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> Date: Thu, 2 Feb 2017 14:41:21 -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.

>> 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 :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25592: Feature request: sorting overlays

[Eli Zaretskii]

> 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 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 ;-)

bug#25592: Feature request: sorting overlays

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1926 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25592: Feature request: sorting overlays

[Johan Bockgård]

Eli Zaretskii <eliz@gnu.org> writes:

> How did you implement in Lisp the "last resort" of comparison, which
> compares addresses of the C structs?

Use sxhash?

bug#25592: Feature request: sorting overlays

[Eli Zaretskii]

> Cc: 25592@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Fri, 3 Feb 2017 16:51:24 -0500
> 
> >> 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).

Why would you need to keep track of overlays, if you always process
each one just once?

As for costs, next-overlay-change (or one of its variants) is used by
the display engine in its inner loops (see
compute_display_string_pos), so it should be fast enough for your
needs, I think.

> 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.

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?

> >>> 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.

bug#25592: Feature request: sorting overlays

[Eli Zaretskii]

> From: Johan Bockgård <bojohan@gnu.org>
> Cc: Clément Pit--Claudel <clement.pitclaudel@live.com>,
>   25592@debbugs.gnu.org
> Date: Sat, 04 Feb 2017 00:28:19 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How did you implement in Lisp the "last resort" of comparison, which
> > compares addresses of the C structs?
> 
> Use sxhash?

Doesn't that return an unsigned value?  sort_overlays compares the
addresses as signed values.

bug#25592: Feature request: sorting overlays

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 5741 bytes --]

On 2017-02-04 03:13, Eli Zaretskii wrote:
>> Cc: 25592@debbugs.gnu.org From: Clément Pit--Claudel
>> <clement.pitclaudel@live.com> Date: Fri, 3 Feb 2017 16:51:24 -0500
>> 
>>>> 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).
> 
> 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?
 
> As for costs, next-overlay-change (or one of its variants) is used
> by the display engine in its inner loops (see 
> compute_display_string_pos), so it should be fast enough for your 
> needs, I think.

I see, thanks.  I'll consider this option, then!

>> 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.
> 
> 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--filter-plist (plist props)
  "Remove PROPS from PLIST."
  (let ((filtered nil))
    (esh--doplist (prop val plist)
      (unless (memq prop props)
        (push prop filtered)
        (push val filtered)))
    (nreverse filtered)))

(defun esh--number-or-0 (x)
  "Return X if X is a number, 0 otherwise."
  (if (numberp x) x 0))

(defun esh--augment-overlay (ov)
  "Return a list of three values: the priorities of overlay OV, and OV."
  (let ((pr (overlay-get ov 'priority)))
    (if (consp pr)
        (list (esh--number-or-0 (car pr)) (esh--number-or-0 (cdr pr)) ov)
      (list (esh--number-or-0 pr) 0 ov))))

(defun esh--augmented-overlay-< (ov1 ov2)
  "Compare two lists OV1 OV2 produced by `esh--augment-overlay'."
  (or (< (car ov1) (car ov2))
      (and (= (car ov1) (car ov2))
           (< (cadr ov1) (cadr ov2)))))

(defun esh--buffer-overlays (buf)
  "Collects overlays of BUF, in order of increasing priority."
  (let* ((ovs (with-current-buffer buf (overlays-in (point-min) (point-max))))
         (augmented (mapcar #'esh--augment-overlay ovs))
         (sorted (sort augmented #'esh--augmented-overlay-<)))
    (mapcar #'cl-caddr sorted)))

(defconst esh--overlay-specific-props
  '(after-string before-string evaporate isearch-open-invisible
                 isearch-open-invisible-temporary priority window)
  "Properties that only apply to overlays.")

(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)))))

I can trim the code to remove bits that are not directly relevant, if you want.

>>>>> 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?

Thanks for your comments!
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25592: Feature request: sorting overlays

[Eli Zaretskii]

> 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.

bug#25592: Feature request: sorting overlays

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 584 bytes --]

On 2017-02-05 13:28, Eli Zaretskii wrote:
> What will happen if you have 2 overlays like this:
> 
>                +------------- OV2 -------+
>    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>    +------- OV1 ---------+
> 
> and OV2 has a higher priority than OV1?

The two overlays get sorted as (OV1 OV2).  Then my code applies OV1's properties to the range covered by OV1, and OV2's properties to the range covered by OV2, which override those of OV1 in the overlapping range (except in the case of face properties, which get appended instead of overriding).

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25592: Feature request: sorting overlays

[Eli Zaretskii]

> Cc: 25592@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sun, 5 Feb 2017 14:10:40 -0500
> 
> > What will happen if you have 2 overlays like this:
> > 
> >                +------------- OV2 -------+
> >    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >    +------- OV1 ---------+
> > 
> > and OV2 has a higher priority than OV1?
> 
> The two overlays get sorted as (OV1 OV2).

But OV2 has a higher priority, so it should be the first in the sorted
order, no?

bug#25592: Feature request: sorting overlays

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 643 bytes --]

On 2017-02-05 14:43, Eli Zaretskii wrote:
>> Cc: 25592@debbugs.gnu.org
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> Date: Sun, 5 Feb 2017 14:10:40 -0500
>>
>>> What will happen if you have 2 overlays like this:
>>>
>>>                +------------- OV2 -------+
>>>    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>    +------- OV1 ---------+
>>>
>>> and OV2 has a higher priority than OV1?
>>
>> The two overlays get sorted as (OV1 OV2).
> 
> But OV2 has a higher priority, so it should be the first in the sorted
> order, no?

I process them in order of increasing priority, so OV1 gets processed first.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25592: Feature request: sorting overlays

[Eli Zaretskii]

> Cc: 25592@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sun, 5 Feb 2017 14:51:55 -0500
> 
> >>> What will happen if you have 2 overlays like this:
> >>>
> >>>                +------------- OV2 -------+
> >>>    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >>>    +------- OV1 ---------+
> >>>
> >>> and OV2 has a higher priority than OV1?
> >>
> >> The two overlays get sorted as (OV1 OV2).
> > 
> > But OV2 has a higher priority, so it should be the first in the sorted
> > order, no?
> 
> I process them in order of increasing priority, so OV1 gets processed first.

So you actually apply _all_ of the overlays in the buffer, one by one?
That's really inefficient.  With my proposal, you'd only need to apply
at most one overlay at each position where some overlay begins or
ends, and do that for much fewer text segments.

bug#25592: Feature request: sorting overlays

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1247 bytes --]



On 2017-02-07 12:13, Eli Zaretskii wrote:
>> Cc: 25592@debbugs.gnu.org
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> Date: Sun, 5 Feb 2017 14:51:55 -0500
>>
>>>>> What will happen if you have 2 overlays like this:
>>>>>
>>>>>                +------------- OV2 -------+
>>>>>    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>    +------- OV1 ---------+
>>>>>
>>>>> and OV2 has a higher priority than OV1?
>>>>
>>>> The two overlays get sorted as (OV1 OV2).
>>>
>>> But OV2 has a higher priority, so it should be the first in the sorted
>>> order, no?
>>
>> I process them in order of increasing priority, so OV1 gets processed first.
> 
> So you actually apply _all_ of the overlays in the buffer, one by one?
> That's really inefficient.  With my proposal, you'd only need to apply
> at most one overlay at each position where some overlay begins or
> ends, and do that for much fewer text segments.

I think I may have misunderstood your proposal, or failed to express what I was trying to achieve :/  If OV1 has face "(:weight bold)" and OV2 has face "(:slant italic)", I want to save both 'face properties. Can I really do that by applying at most one overlay at each position?

Clément.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25592: Feature request: sorting overlays

[Eli Zaretskii]

> Cc: 25592@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Tue, 7 Feb 2017 14:17:13 -0500
> 
> >> I process them in order of increasing priority, so OV1 gets processed first.
> > 
> > So you actually apply _all_ of the overlays in the buffer, one by one?
> > That's really inefficient.  With my proposal, you'd only need to apply
> > at most one overlay at each position where some overlay begins or
> > ends, and do that for much fewer text segments.
> 
> I think I may have misunderstood your proposal, or failed to express what I was trying to achieve :/  If OV1 has face "(:weight bold)" and OV2 has face "(:slant italic)", I want to save both 'face properties. Can I really do that by applying at most one overlay at each position?

For the face property, no, because it can have many attributes, and
they must be merged.  Likewise for before-string and after-string
properties.  But still, these overlays are applied by the display
engine in a specific priority order (before-strings in the order of
increasing priority, after-strings in the decreasing order) at that
particular locations.  So you need to do the same to produce the same
effect.

But for other properties, like the display property, yes, you can
apply only the highest.  And that was your original example, AFAIR.

bug#25592: Feature request: sorting overlays

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1213 bytes --]

On 2017-02-07 14:56, Eli Zaretskii wrote:
> For the face property, no, because it can have many attributes, and
> they must be merged.  Likewise for before-string and after-string
> properties.  But still, these overlays are applied by the display
> engine in a specific priority order (before-strings in the order of
> increasing priority, after-strings in the decreasing order) at that
> particular locations.  So you need to do the same to produce the same
> effect.

Indeed, but I don't need to re-sort them at each position: I can just sort them once and for all, can't I?

> But for other properties, like the display property, yes, you can
> apply only the highest.

Yup, that makes sense.  

> And that was your original example, AFAIR.

I don't remember; sorry if I was unclear :/  The face property is one of the ones I care most about, because it's one of the few ones for which "text-property-at" isn't enough.

I will try to implement your approach of iterating over ranges of text.  Thanks for all the pointers! Independently of my use case, though, would you object to a patch adding a function that takes a list of overlays from the same buffer and sorts them?

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25592: Feature request: sorting overlays

[Eli Zaretskii]

> Cc: 25592@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Tue, 7 Feb 2017 15:07:19 -0500
> 
> would you object to a patch adding a function that takes a list of overlays from the same buffer and sorts them?

I don't think such a functionality will see too much use.  But won't
object if someone wants to implement it.

bug#25592: Feature request: sorting overlays

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 556 bytes --]

On 2017-02-08 12:22, Eli Zaretskii wrote:
>> Cc: 25592@debbugs.gnu.org
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> Date: Tue, 7 Feb 2017 15:07:19 -0500
>>
>> would you object to a patch adding a function that takes a list of overlays from the same buffer and sorts them?
> 
> I don't think such a functionality will see too much use.  But won't
> object if someone wants to implement it.

Ok. I'll consider implementing this, but I'll implement your other suggestion first.  This bug can be closed :)

Thanks!
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]