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

[Stephen Berman]

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

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