[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40821: Margin strings are displayed in reverse order of overlay prio
From: |
Clément Pit-Claudel |
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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 25/04/2020 13.36, Eli Zaretskii wrote:
>> Cc: 40821@debbugs.gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@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.
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Clément Pit-Claudel, 2020/04/24
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Eli Zaretskii, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Clément Pit-Claudel, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Eli Zaretskii, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Clément Pit-Claudel, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Eli Zaretskii, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Clément Pit-Claudel, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Eli Zaretskii, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Dmitry Gutov, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones),
Clément Pit-Claudel <=