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

Previous Next

Package: emacs;

Reported by: Clément Pit-Claudel <cpitclaudel <at> gmail.com>

Date: Fri, 24 Apr 2020 15:57:01 UTC

Severity: wishlist

Full log


Message #28 received at 40821 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
Cc: 40821 <at> debbugs.gnu.org
Subject: Re: bug#40821: Margin strings are displayed in reverse order of
 overlay priority (low-priority specs hide high-priority ones)
Date: Sat, 25 Apr 2020 20:36:07 +0300
> 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?

The handling of overlays by their priorities is mainly for when each
overlay is created by a different Lisp program, when coordination is
hard or impossible.  This is not the case here.

> > As expected: faces are merged, but fringe bitmaps aren't.
> 
> Yes, which is the outlandish part :)

I don't think I see it that way.

> > What you described is actually the order of _increasing_ priority.  Or
> > am I confused?
> 
> Of, yes, you're completely right; sorry for mixing up the terms.
> I meant to say that, if highest-priority overlays were displayed first in the margin, then on narrow margins specs from high-priority overlays would take precedence.

And we are right back to square 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.

I'm not saying this just out of stubbornness.  Handling of overlays is
a notoriously complex part of the display engine, because they
interact with faces, invisible properties, and display properties in
complicated ways.  We shouldn't complicate it more where Lisp programs
which create the overlays can DTRT instead.




This bug report was last modified 5 years and 37 days ago.

Previous Next


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