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

[Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Romain Ouabdelkader <romain.ouabdelkader@gmail.com> writes:
> 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:
> Screenshot 2024-10-20 at 16.56.48.png
> Here, when press C-n once, I expect the cursor to go here:
> 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 think that's indeed the ideal.

> 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:
> Screenshot 2024-10-20 at 17.00.18.png
>
> What do you think? 

I think this behavior is bad, so I don't think this is a good patch.
Note especially that C-e puts point after the diagnostic, then DEL
deletes characters before the diagnostic!  Unexpected and confusing IMO.

That's equivalent to the behavior without the 'cursor property: point
goes to the end of the displayed diagnostic, both on C-e and C-n.

There are two conflicting issues here:

A. Having "point is at EOL" be displayed as "the cursor is after the
   diagnostic" is unacceptable because it means DEL deletes characters at
   a distance, and other similar bad issues.

   So we want "point is at EOL" to be displayed as "the cursor is before
   the diagnostic", which the existing 'cursor property achieves.

B. (vertical-motion 1) tries to move the cursor to after the diagnostic,
   since that's the next screen line.  Then the cursor property displays
   the cursor back to before the diagnostic.  Since that ends up moving
   point to the end of the current line, which is the same visual line,
   this is unexpected.

A is more important than B, so if we want to fix B we can't break A.

Here's a self-contained demonstration without flymake:

(with-current-buffer (get-buffer-create "*overlay-demonstration*")
  (erase-buffer)
  (remove-overlays)
  (insert (make-string 80 ?x))
  (save-excursion
    (newline)
    (insert (make-string 80 ?y)))
  (let ((ol (make-overlay (point) (1+ (point))))
        (s (propertize (make-string 80 ?s) 'face 'warning)))
    (put-text-property 0 1 'cursor t s)
    (overlay-put ol 'before-string s))
  (delete-other-windows)
  (let ((win (split-window-right -62)))
    (set-window-buffer win (current-buffer)))
  (other-window 1))

If you run this then you'll observe behavior B when moving with C-n and
C-p.

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.

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

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?