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

[Romain Ouabdelkader <romain.ouabdelkader@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2534 bytes --]

Sorry, I realized I wasn't clear about the behavior I was expecting.

I would expect the cursor behavior to remain consistent whether diagnostics
are present or not, especially since diagnostics can appear and disappear
during editing.

For example:
[image: Screenshot 2024-10-20 at 16.56.48.png]
Here, when press C-n once, I expect the cursor to go here:
[image: Screenshot 2024-10-20 at 16.57.59.png]

I.e. the behavior would be the same as if there were no diagnostics in the
buffer.
I'm not sure if that's actually feasible or if there is an issue with this
behavior.

I tried your patch but it makes the cursor go on the diagnostic which i
find surprising, I believe the cursor should not be able to move into a
diagnostic:
[image: Screenshot 2024-10-20 at 17.00.18.png]

What do you think?

On Sun, Oct 20, 2024 at 4:42 PM João Távora <joaotavora@gmail.com> wrote:

> 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.
>
> 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.
>
> João
>

[-- Attachment #1.2: Type: text/html, Size: 3187 bytes --]

[-- Attachment #2: Screenshot 2024-10-20 at 16.56.48.png --]
[-- Type: image/png, Size: 40336 bytes --]

[-- Attachment #3: Screenshot 2024-10-20 at 16.57.59.png --]
[-- Type: image/png, Size: 39434 bytes --]

[-- Attachment #4: Screenshot 2024-10-20 at 17.00.18.png --]
[-- Type: image/png, Size: 36838 bytes --]