GNU bug report logs - #40821
Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones)

Previous Next

Full log

View this message in rfc822 format

From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 40821 <at> debbugs.gnu.org
Subject: bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones)
Date: Sat, 25 Apr 2020 16:50:03 -0400

On 25/04/2020 13.36, Eli Zaretskii wrote:
>> Cc: 40821 <at> debbugs.gnu.org
>> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
>> Date: Sat, 25 Apr 2020 13:21:13 -0400
>>
>>> Yes, but is it reasonable to ask the display engine to figure that out
>>> for you?  You are talking about something that is clearly application
>>> logic; other applications might want some other logic to have other
>>> overlays "win".
>>
>> I think it is reasonable: we already have a notion of overlays "winning", namely their priority.
> 
> But you want to change that, based I don't really understand on what?

I think we're getting too closely attached to a specific use case.  There's a simple problem with the margins: you put two overlays on one line, they both have margin specs, they both have faces with a foreground.  One is priority 100, the other 0.  The margin is 1-character wide.  Then you see just one thing in the margin: the spec from the low-priority overlay.  And you see one face in the buffer: the one from the high priority overlay.

I'm saying it doesn't make much sense.  Same for the fringes.  Of course, it's not specified, so nowhere have committed to this broken behavior or to any other beahvior at this point.
But that doesn't make it less broken: the one mechanism we have for determining which overlay wins (priorities) applies in reverse for the fringes and the margins.
Maybe what we need is a more general mechanism for deciding which spec wins, if you don't think priority is the right one.

> I can only reiterate my suggestion: don't rely on the display engine
> to solve the problems in such cases.  The best solution is for the
> Lisp program to apply its logic and put only the overlays it needs.
> …
> We shouldn't complicate it more where Lisp programs
> which create the overlays can DTRT instead.

Then TRT sounds a lot like reimplementing a part of the display engine in ELisp: iterating over overlays on each line, sorting them by priority, taking their margin specs and fringes, determining the highest priority one, and displaying that in the margin/fringe, for each modified line, after each command.  And ideally, doing that lazily too, to avoid doing work on the whole buffer at once and slowing editing down.  Isn't that the job description of the display engine?

Thanks for your help,
Clément.  

Previous Next

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