--- Begin Message ---
|
Subject: |
25.1.50; Cursor motion error with visual-line-mode |
|
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.
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#23570: 25.1.50; Cursor motion error with visual-line-mode |
|
Date: |
Mon, 23 May 2016 05:36:55 +0300 |
> From: Chong Yidong <address@hidden>
> Cc: address@hidden
> 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.
--- End Message ---