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

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 18 Sep 2023 16:31:45 +0100
> Cc: jporterbugs@gmail.com, 66041@debbugs.gnu.org
> 
> On Mon, Sep 18, 2023 at 3:32 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > I guess you want the cursor on the first character of the
> > overlay-string that is displayed first (leftmost)?  Are you asking how
> > to implement this when there are more than one overlay at EOB?
> 
> Yes, a direct answer to that question would be nice to know, too.

Give your overlays different priorities, and use (cursor t) only in
the overlay of the highest priority.  If they all have before-string
(which is what I saw in the example), then priority will determine
which overlay is processed first (and thus displayed first).

> The idea is to have multiple bits of diagnostic text displayed
> after the end-of-line each related to a source overlay contained
> within that line.  The idea of the feature is that source overlay
> and eol text are linked.  If the source overlay is deleted, the
> end-of-line should disappear.
> 
> It's similar to what happens with a simple 'after-string' overlay
> property, but with the 'after-string' skipping over all characters
> until the end of line.
> 
> Currently, I'm doing this with a single "end-of-line" overlay placed
> as I explained properly (modulo bugs like this one, of course, since
> I intended a single overlay but unexpectedly got two).  It's this
> second end-of-line overlay which has an 'after-string' property. I use
> after change functions to control the value of this property, so that
> if a source overlays gets destroyed, the corresponding text in value
> is deleted (and eventually also
> 
> But I could probably use multiple end-of-line overlays, with a
> one-to-one correspondence to the source overlays.  I've tried that too
> but abandoned it for difficulty in placing the cursor (similar problem
> to this one).
> 
> And I think I tried an overlay modification hook instead of buffer after
> change functions and abandoned it too for some reason.  Maybe the
> modification hook isn't called at all when the overlay is completely
> deleted?
> 
> Or, conceivably, it could be done without end-of-line overlays at all,
> if somehow a 'eol-string' property similar to 'after-string' was
> implemented in the C code.  But I would prefer a Lisp solution, of
> course.
> 
> So, in summary, there is a fair bit of design space for this feature
> (which exists in VS code, btw) and I wanted to know your thoughts
> on these possibilities and my decisions.

Is placing the cursor the only problem you need to solve?

And do I understand correctly that you normally collect all the
diagnostics into a single sting, and display it as a single overlay
string?