bug#23570: 25.1.50; Cursor motion error with visual-line-mode

bug#23570: 25.1.50; Cursor motion error with visual-line-mode

[Chong Yidong]

When visual-line mode is enabled, there is a bug causing the cursor to
fail to find the right start/end of a screen line.  I see the bug with
Emacs 24.5, as well as the latest git version.  No bug in Emacs 24.4.

1. emacs -Q

2. Insert the following (at the start of a new line):

123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 ABCDEFGHIJK  MOPQ

3. M-x visual-line-mode RET

4. Adjust the window width until it is just large enough for
   "ABCDEFGHIJK" to be on the first line.

5. Decrease the window width by 1 character.  Now, "ABCDEFGHIJK" should
   be wrapped to the second line.

5. Move point to the beginning of the line starting with "1234...".
   Now, typing C-e moves to the second screen line.  Expected result: it
   should move to the end of the first screen line.

   Various other screen oddities are observable in the vicinity of this
   wrapped line.  For instance, when point is on "Q", C-a moves to the
   space before "M", rather than the start of the line.


In GNU Emacs 25.1.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.20.3)
 of 2016-05-17 built on tsparkle
Repository revision: 631ca55c6decccca2dc0961dc28962819eacc35b
Windowing system distributor 'The X.Org Foundation', version 11.0.11801000
System Description:	Arch Linux

bug#23570: 25.1.50; Cursor motion error with visual-line-mode

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Date: Wed, 18 May 2016 19:20:28 +0800
> 
> When visual-line mode is enabled, there is a bug causing the cursor to
> fail to find the right start/end of a screen line.  I see the bug with
> Emacs 24.5, as well as the latest git version.  No bug in Emacs 24.4.
> 
> 1. emacs -Q
> 
> 2. Insert the following (at the start of a new line):
> 
> 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 ABCDEFGHIJK  MOPQ
> 
> 3. M-x visual-line-mode RET
> 
> 4. Adjust the window width until it is just large enough for
>    "ABCDEFGHIJK" to be on the first line.
> 
> 5. Decrease the window width by 1 character.  Now, "ABCDEFGHIJK" should
>    be wrapped to the second line.
> 
> 5. Move point to the beginning of the line starting with "1234...".
>    Now, typing C-e moves to the second screen line.  Expected result: it
>    should move to the end of the first screen line.
> 
>    Various other screen oddities are observable in the vicinity of this
>    wrapped line.  For instance, when point is on "Q", C-a moves to the
>    space before "M", rather than the start of the line.

I cannot say I can reproduce this on my machine.  I see something
similar in Emacs 24.5, but not with the current master or release
branch.

I think what you see could be explained by changing the frame size by
non-integer number of characters (i.e. by a number of pixels that is
smaller than the canonical character width).  But since I cannot come
up with a reproducible recipe, I cannot debug this.

bug#23570: 25.1.50; Cursor motion error with visual-line-mode

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> I cannot say I can reproduce this on my machine.  I see something
> similar in Emacs 24.5, but not with the current master or release
> branch.
>
> I think what you see could be explained by changing the frame size by
> non-integer number of characters (i.e. by a number of pixels that is
> smaller than the canonical character width).  But since I cannot come
> up with a reproducible recipe, I cannot debug this.

The recipe does not describe changing the frame size by non-integer
number of characters.  I'm changing the frame (hence window) size by
dragging the frame border; the width changes by one character at a time.

To remove all ambiguity, here is another recipe using elisp:

1. emacs -Q

2. Insert the following:

(defun foo ()
  (interactive)
  (save-excursion
    (dotimes (x 7)
      (insert "123456789 "))
    (insert "12 ABCDEFGHIJK  MOPQ"))
  (visual-line-mode)
  (set-frame-parameter nil 'width 85))

3. M-x eval-buffer RET

4. M-x foo RET

5. C-e  => cursor goes to the wrong place.

bug#23570: 25.1.50; Cursor motion error with visual-line-mode

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: 23570@debbugs.gnu.org
> Date: Thu, 19 May 2016 10:58:42 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think what you see could be explained by changing the frame size by
> > non-integer number of characters (i.e. by a number of pixels that is
> > smaller than the canonical character width).  But since I cannot come
> > up with a reproducible recipe, I cannot debug this.
> 
> The recipe does not describe changing the frame size by non-integer
> number of characters.  I'm changing the frame (hence window) size by
> dragging the frame border; the width changes by one character at a time.

Not in Emacs 24.5 and later: the resizing is pixel-wise, at least
here.

> To remove all ambiguity, here is another recipe using elisp:

Thanks, I will look into this.

bug#23570: 25.1.50; Cursor motion error with visual-line-mode

[martin rudalics]

 >> The recipe does not describe changing the frame size by non-integer
 >> number of characters.  I'm changing the frame (hence window) size by
 >> dragging the frame border; the width changes by one character at a time.
 >
 > Not in Emacs 24.5 and later: the resizing is pixel-wise, at least
 > here.

Resizing frames with GTK is still character-wise by default.

martin

bug#23570: 25.1.50; Cursor motion error with visual-line-mode

[Eli Zaretskii]

> Date: Thu, 19 May 2016 07:38:33 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 23570@debbugs.gnu.org
> 
> > To remove all ambiguity, here is another recipe using elisp:
> 
> Thanks, I will look into this.

Is it correct that the problem happens only when the line wraps at
whitespace that has more than one whitespace character?  Your recipes
both have that, but the subject is more general, and I wonder what
your real-life use cases where.

If I replace one of the spaces with a non-whitespace character, the
problem goes away.

bug#23570: 25.1.50; Cursor motion error with visual-line-mode

[Eli Zaretskii]

> Date: Thu, 19 May 2016 19:50:02 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 23570@debbugs.gnu.org
> 
> Is it correct that the problem happens only when the line wraps at
> whitespace that has more than one whitespace character?

Sorry, this wording is inaccurate.  What I meant to say is that the
first word that wraps to the next screen line is followed by more than
one whitespace character.  In your recipe, that would be the 2 spaces
in "ABCDEFGHIJK  MOPQ".

bug#23570: 25.1.50; Cursor motion error with visual-line-mode

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> the first word that wraps to the next screen line is followed by more
> than one whitespace character.  In your recipe, that would be the 2
> spaces in "ABCDEFGHIJK MOPQ".

Yes, the two whitespaces on the wrapped line seem to be necessary to
trigger the bug.

> I wonder what your real-life use cases where

I came across this while editing a LaTeX document, and the two white
spaces that triggered the bug were the usual two spaces after a full
stop.  I'd previously noticed the bug on a couple of occasions, sometime
after the Emacs 24.4 release, but didn't manage to get a reproducible
recipe until now.

bug#23570: 25.1.50; Cursor motion error with visual-line-mode

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: 23570@debbugs.gnu.org
> Date: Fri, 20 May 2016 09:54:17 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > the first word that wraps to the next screen line is followed by more
> > than one whitespace character.  In your recipe, that would be the 2
> > spaces in "ABCDEFGHIJK MOPQ".
> 
> Yes, the two whitespaces on the wrapped line seem to be necessary to
> trigger the bug.
> 
> > I wonder what your real-life use cases where
> 
> I came across this while editing a LaTeX document, and the two white
> spaces that triggered the bug were the usual two spaces after a full
> stop.  I'd previously noticed the bug on a couple of occasions, sometime
> after the Emacs 24.4 release, but didn't manage to get a reproducible
> recipe until now.

Thanks, I've pushed a fix to the master branch (commit 99848b3).
Please test.

(I think this change is too low-level to be safe for the emacs-25
branch at this late stage of pretest.)

bug#23570: 25.1.50; Cursor motion error with visual-line-mode

[Chong Yidong]

> Thanks, I've pushed a fix to the master branch (commit 99848b3).
> Please test.
>
> (I think this change is too low-level to be safe for the emacs-25
> branch at this late stage of pretest.)

Thanks, verified that the bug seems to be fixed now.

FWIW, I think the fix ought to be considered for the emacs-25 branch,
since (i) it is a regression relative to Emacs 24.4, and (ii) it is
quite simple to trigger on natural-language text with long lines, which
should be considered a common use-case.

bug#23570: 25.1.50; Cursor motion error with visual-line-mode

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: 23570@debbugs.gnu.org
> Date: Mon, 23 May 2016 10:09:39 +0800
> 
> > Thanks, I've pushed a fix to the master branch (commit 99848b3).
> > Please test.
> >
> > (I think this change is too low-level to be safe for the emacs-25
> > branch at this late stage of pretest.)
> 
> Thanks, verified that the bug seems to be fixed now.

Thanks, closing.

> FWIW, I think the fix ought to be considered for the emacs-25 branch,
> since (i) it is a regression relative to Emacs 24.4, and (ii) it is
> quite simple to trigger on natural-language text with long lines, which
> should be considered a common use-case.

I considered that, but since the release is imminent, I was uneasy to
put such low-level changes in basic functionality in the release.

John, would you please provide a second opinion here?

Thanks.

bug#23570: 25.1.50; Cursor motion error with visual-line-mode

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> FWIW, I think the fix ought to be considered for the emacs-25 branch, since
>> (i) it is a regression relative to Emacs 24.4, and (ii) it is quite simple
>> to trigger on natural-language text with long lines, which should be
>> considered a common use-case.

> I considered that, but since the release is imminent, I was uneasy to put
> such low-level changes in basic functionality in the release.

> John, would you please provide a second opinion here?

This should wait for 25.2. It's a cursor motion error, not data loss, and
these sorts of low-level changes are too much at this point.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]