bug#73863: 30.0.91; Unexpected cursor movement with flymake-show-diagnostics-at-end-of-line

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 20 Oct 2024 15:42:15 +0100
> Cc: sbaugh@janestreet.com, romain.ouabdelkader@gmail.com, 
> 	73863@debbugs.gnu.org
> 
> On Sun, Oct 20, 2024 at 12:49 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > That would mean a non-trivial code in flymake.el, because it would
> > need to decide in advance whether the diagnostic will fit on the same
> > screen line.  Moreover, if the user then makes the window wider or
> > narrower, the cursor will jump between two screen positions, something
> > that I think is highly undesirable (and will look like a bug).
> 
> Yes, you're right, but the solution you propose is arguably harmful for
> the current case.  If I'm at line n, column c and I move down to line n+1 with
> less than c columns, and that line n+1 has a wrapping diagnostic at eol, I now
> see that a single 'down' makes the cursor jump multiple screen lines
> to the end
> of said diagnostic, and that's not really pretty either.  And even
> closer to this
> report's scenario, your solution only makes some sense if the overlays happen
> to only wrap one line: it ceases to make sense in very narrow windows
> where the overlays wrap multiple lines.

Emacs can only display the cursor either before or after the overlay
string.  Anything else requires the 'cursor' property to be placed
dynamically, depending on what is column c in your scenario, and I
don't think it's reasonable to require flymake.el to jump through such
hoops.

> IMO, wrapping these annotations is more distracting than useful.
> They're meant to be minimally intrusive auxiliary visual aids, and causing
> screen line increase violates that.  Note that the full diagnostic info can be
> viewed via eldoc in the echo area for example, where there are options to
> control length and jumping (and where window width isn't an issue).
> 
> So I advise to turn on line truncation when using them, or to live with the
> current idiosyncrasy instead of another equivalent (IMO slightly worse)
> idiosyncrasy.

That is also fine by me.  But note that the code itself could have
lines that wrap, and in that case, line truncation will make some of
the code invisible until horizontally-scrolled into view.

So it's a difficult situation.  Was displaying the diagnostic in a
tooltip ever considered as the alternative to this past-EOL display?