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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 25 Sep 2023 13:12:50 +0100
> Cc: jporterbugs@gmail.com, 66041@debbugs.gnu.org
> 
> On Mon, Sep 25, 2023 at 1:09 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: João Távora <joaotavora@gmail.com>
> > > Date: Mon, 25 Sep 2023 12:46:35 +0100
> > > Cc: jporterbugs@gmail.com, 66041@debbugs.gnu.org
> > >
> > > On Mon, Sep 25, 2023 at 11:32 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > > Add some character after the SPC, even a newline, and the display will
> > > > be as you expect.
> > >
> > > I think that's only because this newline will, by default, delete the SPC
> > > character and thus resolve the diagnostic from checkdoc, deleting the
> > > overlay.
> >
> > No, because if you insert any other character after the space, the
> > display will also be as you expect.
> 
> Obviously, because any other character which is not space
> will _also_ fix the trailing whitespace diagnostic issued by the
> checkdoc backend. By definition :-)

OK, let's back up a notch, because I think I've misunderstood you.

What you have here are two separate overlays, each with a
before-string.  The overlays cover two completely disjoint portions of
buffer text: 1 to 6 for the first overlay, 6 to 7 for the second.

Now, priorities are only relevant for overlays that cover overlapping
portions of text.  In your case, there's no overlap, so both overlays
will be displayed.  Try this variant:

  (let (ov)
    (setq ov (make-overlay 1 6))
    (overlay-put ov 'before-string "B1")
    (overlay-put ov 'priority 42)
    (setq ov (make-overlay 6 7))
    (overlay-put ov 'before-string "B2")
    (overlay-put ov 'priority 41))

You will see that "B1" is displayed before "hello" and "B2" is
displayed before the space that follows "hello", like this:

  B1helloB2

Both overlays show on display regardless of their priorities.  Right?

That is exactly what happens in your case: both overlays are
displayed.  Except that in your case the before-strings have a
'display' property on them, whose value draws a bitmap on the fringe,
instead of showing the string itself in the text-area.  What Emacs
does is again display both overlays, both of which draw a bitmap on
the same fringe, so what you see is the bitmap which is drawn last.
Because when some 'display' property draws on the fringe, we draw it
unconditionally, regardless of priorities etc.  So the last bitmap
drawn on the fringe "wins".  And since the display engine processes
overlays in the order of buffer positions (for left-to-right text),
the overlay that wins is always the last one.

Does this explain what happens?