Subject: Re: bug#66041: 30.0.50; Should 'flymake-note-echo' inherit from 'compilation-info'?

From: Eli Zaretskii <[email-masked]>
Date: Mon, 25 Sep 2023 20:23:57 +0300

> From: João Távora <[email-masked]>
> Date: Mon, 25 Sep 2023 17:55:45 +0100
> Cc: [email-masked], [email-masked]
> 
> > There's no built-in mechanism for the display engine to do that, and
> > the fact that overlays are processed one by one in the order they are
> > encountered doesn't help: when processing an overlay the display
> > engine has no idea there are other overlays in the same screen line
> > that will "compete" for the fringe display.
> 
> Could it be changed, as it analyses a line, to keep a record of
> which overlays have already touched the left fringe for that line
> (and then clear this record as it moves on to other lines).

The display engine does not analyze lines.  It starts where it is told
to start, and goes on, one buffer position at a time, until some other
buffer position, where it was told to stop.  To analyze lines means
scan each line twice, and the apply some (as yet undefined) logic.

> This would be easiest to implement if the the display doesn't
> sometimes consider only a fraction of a line.I don't know if this
> holds true.

That happens in some situations, yes.

> I assume it does, since otherwise that would mean that
> if a line is scrolled near the beginning and truncated, the current
> "last one" criteria you described before also doesn't always
> hold true.

The "last one" means the last overlay processed on a screen line.

> IMHO this should be automatic and based on relative overlay
> priorities.

Overlay priorities are not for overlays that cover disjoint portions
of text.  Also, the same problem will happen when several 'display'
properties that draw on the fringe are put on buffer text, without any
overlays and thus without any priorities to begin with.  So if we want
to implement something like this in the display engine, we'd need to
extend the format of the 'display' property in this case, adding some
kind of "priority" there, or maybe extend the fringe bitmap data
itself.