Subject: Re: bug#73863: 30.0.91; Unexpected cursor movement with flymake-show-diagnostics-at-end-of-line
From: Eli Zaretskii <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Sat, 30 Nov 2024 11:45:22 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

> Cc: [email-masked], [email-masked], [email-masked]
> Date: Wed, 13 Nov 2024 16:45:27 +0200
> From: Eli Zaretskii <[email-masked]>
> 
> > From: Spencer Baugh <[email-masked]>
> > Cc: João Távora <[email-masked]>,  Eli Zaretskii
> >   <[email-masked]>,
> >    [email-masked]
> > 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.

No further comments within more than 2 weeks, so I'm no closing this
bug.