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

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: João Távora <joaotavora@gmail.com>,  Eli Zaretskii
>   <eliz@gnu.org>,
>    73863@debbugs.gnu.org
> Date: Tue, 12 Nov 2024 16:38:43 -0500
> 
> There's actually another symmetric issue to B: after moving to the end
> of the line with C-e, if you hit C-p that moves to the start of the
> current screen line, instead of moving to the previous screen line.
> This is because vertical-motion acts as if the cursor is on screen line
> 3, when it's actually on screen line 2 because of the 'cursor property.
> 
> Arguably this is a bug in vertical-motion: if you run (vertical-motion
> 1) or (vertical-motion -1) in the appropriate places, it returns 1 or
> -1, claiming that it moved by a screen line even though it actually
> stayed on the same screen line.

No, it isn't a bug: vertical-motion works with point, not with the
screen position of the cursor.  And point is on the next screen line,
because the diagnostic overlay "covers" the newline at EOL.

> I'm not sure how to fix this.  IMO, vertical-motion should try harder to
> move by screen lines.

Feel free to teach vertical-motion about the 'cursor' property.  I
don't plan on doing that any time soon, having spent numerous hours on
making that function cater to quite a few complications.

> In the C-p case, there's an obviously correct thing to do: move to the
> same column of the previous screen line.  But for some reason,
> vertical-motion doesn't do it: it stays on the same screen line.  Maybe
> fixing this should start there?

See above: vertical-motion works perfectly correctly in that case, you
are just tricked by the fact that the 'cursor' property forces us to
show the cursor not where point is.