bug#8155: 23.2; erratic cursor movement with visual-line-mode and wrap-prefix property

[Stephen Berman]

On Wed, 02 Mar 2011 16:41:40 +0100 Nicolas Goaziou <n.go...@gmail.com> wrote:

> From `emacs -Q', C-x b whatever to open a new buffer. Then M-x
> visual-line-mode. Now fill a bit more than a screenfull of text without
> inserting a newline. Eventually use (put-text-property 1 (point-max)
> 'wrap-prefix " ").
>
> Now, going from (point-min), use C-n to move down. Near the end of that
> huge paragraph, C-n will not keep a constant column. In the same area,
> C-e and C-a will change line. C-p will go through the same path as C-n,
> thus not keeping the first column as well.

I can reproduce this in GNU/Linux on current master (at commit 0bbc84630).

> Under certain conditions that I have yet to find (but related to that
> property and visual-line-mode), `next-line', when reaching the last line
> of the window, will put point back in the middle of the screen while
> keeping the same buffer portion visible (so it's a loopback, as the next
> part of the buffer is never shown). When it happens, the cursor is stuck
> forever in that loop if the user keep moving with `next-line'. This
> doesn't happen with C-p, and C-v can get out of the loop.

I haven't been able to reproduce this yet.

> In GNU Emacs 23.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.0)
> of 2010-05-08 on pidsley.hoetzel.info

I also have some additional observations:

- The erratic cursor movement also happens when visual-line-mode is
enabled _without_ adding the wrap-prefix property, and with much less
than a screenful of text:
0. emacs -Q
1. Switch to a new buffer, e.g., C-x b a RET
2. Insert this text without any line breaks:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim
ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
aliquip ex ea commodo consequat. Duis aute irure dolor in
reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
3. M-x visual-line-mode
4. Starting from (point-min), type C-n four times.
=> Point is now at 310, before the last word 'eu' of the fourth visual
line, corresponding to visual column 77 of that line.
5. Typing C-n again puts point before the next word 'fugiat', the
first word of the fifth visual line at visual column 1, and another
C-n puts point at visual column 1 of the sixth visual line. Typing
C-p returns point to visual column 77 of the fourth visual line.
6. Repeat step 4, and then type C-a, which moves point to visual
column 1 of visual line 4, then type C-e, which moves point to 309,
visually in the space between 'dolore' and 'eu' in visual line 4.
7. Type C-n again.
=> Point is now at 386, before the 'n' of 'sunt' in visual line 5,
corresponding to visual column 73.
8. Type C-p.
=> Point is now at 231, befor the last character '.' of visual line 3,
corresponding to column 76.
5. Type a space at the end of the text and insert another
copy of the text, so that there are now 12 visual lines.
6. Repeat step 4 and then type C-n three more times.
=> Point is now at 465, before the last word 'sit' of visual line 6.
7. Type C-n three more times.
=> Point is now at 609, before the first letter of the last word on
visual line 9, at visual column 62.
8. Type C-n again.
=> Point is now at 684, before the first letter of the third to last
word on visual line 10, at visual column 62.
9. Type C-n again.
=> Point is now at 689, before the first letter of the second to last
word on visual line 10, at visual column 67.
I have also observed that the positions after C-n as reported above
may be differen when other commands intervenes (already noted with C-a
and C-e, but also e.g. sometimes 'M-: (point)').

- Using the mouse is also effected by visual-line-mode:
10. With the buffer as before step 4 above, clicking mouse-1 anywhere
before position 310 puts point at the position clicked, as usual.
=> But trying to click at any position after 309 put point three
positions (columns) before the position clicked on, e.g., clicking
on the first visual column of visual line 5 locates point at 311,
before the last character of visual line 4.
11. Likewise, trying to select a region with the mouse shows a
corresponding lag between the region end and the mouse pointer,
e.g., clicking with mouse-1 on a position before 309 in visual
line 4, and dragging the mouse while holding down mouse-1 to the
end of visual line 4 -- but not dragging the mouse below visual
line 4 -- selects a region that ends at 309. Only when the mouse
is dragged below line 4 is the region then extended, but its end
is three columns before the location of the mouse pointer.

Steve Berman

[Eli Zaretskii]

> From: Stephen Berman <stephen...@gmx.net>
> Date: Sun, 30 Aug 2020 23:39:07 +0200
> Cc: 81...@debbugs.gnu.org

>
> On Wed, 02 Mar 2011 16:41:40 +0100 Nicolas Goaziou <n.go...@gmail.com> wrote:
>
> > From `emacs -Q', C-x b whatever to open a new buffer. Then M-x
> > visual-line-mode. Now fill a bit more than a screenfull of text without
> > inserting a newline. Eventually use (put-text-property 1 (point-max)
> > 'wrap-prefix " ").
> >
> > Now, going from (point-min), use C-n to move down. Near the end of that
> > huge paragraph, C-n will not keep a constant column. In the same area,
> > C-e and C-a will change line. C-p will go through the same path as C-n,
> > thus not keeping the first column as well.
>
> I can reproduce this in GNU/Linux on current master (at commit 0bbc84630).

I could not. Maybe the recipe needs to be more specific, e.g. to
specify the text to be inserted.

> - The erratic cursor movement also happens when visual-line-mode is
> enabled _without_ adding the wrap-prefix property, and with much less
> than a screenful of text:

This I _could_ reproduce, but only on master. It was introduced by
the changes that added support for word-wrap-by-category, which had a
subtle logic error. So this bug is very recent, and almost certainly
has nothing to do with the one discussed here from the beginning.
That original bug was either solved long ago, or rears its ugly head
only in some very subtle situations, which would explain why I cannot
reproduce it.

> I have also observed that the positions after C-n as reported above
> may be differen when other commands intervenes (already noted with C-a
> and C-e, but also e.g. sometimes 'M-: (point)').
>
> - Using the mouse is also effected by visual-line-mode:

All of the problems you describe are due to a single incorrect 'if'
clause deep in the bowels of the display code. It should be fixed
now.

Thanks.