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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8155 in the body.
You can then email your comments to 8155 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Nicolas Goaziou <n.goaziou <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.2; erratic cursor movement with visual-line-mode and wrap-prefix
	property
Date: Wed, 02 Mar 2011 16:41:40 +0100

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

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.

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.

In GNU Emacs 23.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.0)
 of 2010-05-08 on pidsley.hoetzel.info
Windowing system distributor `The X.Org Foundation', version 11.0.10904000
configured using `configure  '--prefix=/usr' '--sysconfdir=/etc' '--libexecdir=/usr/lib' '--localstatedir=/var' '--mandir=/usr/share/man' '--without-sound' '-with-x-toolkit=gtk' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-optimize-sibling-calls' 'LDFLAGS=-Wl,--hash-style=gnu -Wl,--as-needed''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: fr_FR.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent input:
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p M-t <f1> f C-g <f1> c C-n <f1> c C-n 
M-t M-x r e p o r t - e m <tab> <return>

Recent messages:
Visual-Line mode enabled
Mark set [6 times]
Scanning for dabbrevs...100%
dabbrev-expand: No dynamic expansion for `put-text-pro' found
Scanning for dabbrevs...100%
dabbrev-expand: No dynamic expansion for `put-text-proper' found
call-interactively: End of buffer
nil
Quit
C-n runs the command next-line
C-n runs the command next-line

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml
easymenu mml-sec password-cache mm-decode mm-bodies mm-encode mailcap
mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader
gnus-util netrc time-date mm-util mail-prsvr gmm-utils wid-edit
mailheader canlock sha1 hex-util hashcash mail-utils emacsbug help-fns
dabbrev tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
font-setting tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind system-font-setting
font-render-setting gtk x-toolkit x multi-tty emacs)

-- 
Nicolas Goaziou

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Nicolas Goaziou <n.goaziou <at> gmail.com>
Cc: 8155 <at> debbugs.gnu.org
Subject: Re: bug#8155: 23.2; erratic cursor movement with visual-line-mode
 and wrap-prefix property
Date: Sun, 30 Aug 2020 23:39:07 +0200

On Wed, 02 Mar 2011 16:41:40 +0100 Nicolas Goaziou <n.goaziou <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 8155 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>, n.goaziou <at> gmail.com
Subject: Re: bug#8155: 23.2;
 erratic cursor movement with visual-line-mode and wrap-prefix property
Date: Thu, 03 Sep 2020 16:06:39 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Sun, 30 Aug 2020 23:39:07 +0200
> Cc: 8155 <at> debbugs.gnu.org
> 
> On Wed, 02 Mar 2011 16:41:40 +0100 Nicolas Goaziou <n.goaziou <at> 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.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8155 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>, n.goaziou <at> gmail.com
Subject: Re: bug#8155: 23.2; erratic cursor movement with visual-line-mode
 and wrap-prefix property
Date: Mon, 07 Sep 2020 13:58:36 +0200

On Thu, 03 Sep 2020 16:06:39 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Sun, 30 Aug 2020 23:39:07 +0200
>> Cc: 8155 <at> debbugs.gnu.org
>>
>> On Wed, 02 Mar 2011 16:41:40 +0100 Nicolas Goaziou <n.goaziou <at> 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.

I guess I was mistaken in thinking what I saw was the same thing Nicolas
described: in trying to reproduce it again I find the column changing
already only a few lines down from the begining (which I assume is due
to the new bug you fixed), not just near the end of the paragraph.

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

Indeed, I had neglected to check with Emacs 27, but now did that and do
not see the problem there.

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

Indeed, after rebuilding with your change, I confirm that that problems
I described are gone.  Thanks!  (And I far as I'm concerned this bug can
be closed as fixed.)

Steve Berman

Message #19 received at 8155-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: casouri <at> gmail.com, 8155-done <at> debbugs.gnu.org, n.goaziou <at> gmail.com
Subject: Re: bug#8155: 23.2; erratic cursor movement with visual-line-mode
 and wrap-prefix property
Date: Mon, 07 Sep 2020 17:36:47 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: n.goaziou <at> gmail.com,  8155 <at> debbugs.gnu.org,  Yuan Fu <casouri <at> gmail.com>
> Date: Mon, 07 Sep 2020 13:58:36 +0200
> 
> > 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.
> 
> Indeed, after rebuilding with your change, I confirm that that problems
> I described are gone.  Thanks!  (And I far as I'm concerned this bug can
> be closed as fixed.)

Thanks, done.

Previous Next

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