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

Previous Next

Full log

Message #62 received at 73863 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Romain Ouabdelkader <romain.ouabdelkader <at> gmail.com>
Cc: sbaugh <at> janestreet.com, 73863 <at> debbugs.gnu.org, joaotavora <at> gmail.com
Subject: Re: bug#73863: 30.0.91; Unexpected cursor movement with
 flymake-show-diagnostics-at-end-of-line
Date: Sun, 20 Oct 2024 18:49:27 +0300

> From: Romain Ouabdelkader <romain.ouabdelkader <at> gmail.com>
> Date: Sun, 20 Oct 2024 17:01:44 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, sbaugh <at> janestreet.com, 73863 <at> debbugs.gnu.org
> 
> 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.

That's not possible, because the diagnostic is displayed using an
overlay string, and Emacs cannot show a cursor inside such a string
unless a Lisp program tells it exactly where to put the cursor.  IOW,
for the cursor-positioning purposes, overlay strings are considered as
indivisible chunks of display.

> 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

Under the default value of line-move-visual, this is not possible:
Emacs is required to show the cursor inside the next _screen_ line,
not the next _logical_ line.  Compare that with the situation where
the diagnostic string is part of buffer text -- in that case you'd
want the cursor to end up inside the next screen line, which is
wrapped from the long line starting with "unknown_function".

> 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.

It isn't feasible.

> 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

We could have the cursor after the diagnostic, if we don't put the
'cursor' property at all.

So these are the possible solutions for this situation:

 . don't change anything and live with the minor irregularity in the
   cursor positioning in what I consider to be rare cases
   - variation: turn on truncate-lines in such cases
 . don't put the 'cursor' property on the diagnostic, in which case
   C-n will place the cursor after the end of the diagnostic on the
   screen line where the diagnostic ends
 . put the 'cursor' property at the last character of the diagnostic
   string, and have it displayed there
 . calculate the character on which to put the 'cursor' property
   dynamically using some convoluted logic
 . implement display of diagnostics in a tooltip instead

Any other suggestions?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.