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

Previous Next

Full log

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.

Previous Next

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