bug#31666: Bad interaction between visual-line-mode and wrap-prefix on long lines

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Fri, 01 Jun 2018 09:02:15 +0200
> Cc: Clément Pit-Claudel <clement.pitclaudel@live.com>,
>       31666@debbugs.gnu.org
> 
> > Is it the same as Bug#11759?
> 
> Sounds like it.  This is also an issue in todo-mode, which by default
> enables visual-line-mode and indents with wrap-prefix.  For example,
> here both items have no space after the date, but the second one is too
> long for the window, so Visual Line mode breaks it:
> 
> 1 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/log/
> 2 [May 31, 2018] 
>    
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c0a0351249c1e6a9307224d
>    8337ff8916f4cf138
> 
> It would be nice if the display could be like this:
> 
> 1 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/log/
> 2 [May 31, 2018] 
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c0a035124
>    9c1e6a9307224d8337ff8916f4cf138

I invite the interested parties to review the code which implements
word-wrap.  There are two separate implementations (similar in the
main idea, but quite different in details): one in display_line, which
actually lays out characters for display; the other in
move_it_in_display_line_to, which emulates display without displaying
anything (needed, for example, in vertical-motion).  It is quite
complex, to say the least.

The main difficulty with the above requests, as I see it, is that they
go against the basic design of the Emacs display code, which lays out
characters one screen line at a time.  The current code basically
keeps track of the last whitespace character it saw while walking the
characters to be displayed on a screen line, then backs up to that
place when it finds that the line needs to be continued, ends the
screen line there, and returns, ready to be called to lay out the next
screen line.  What you propose would require it to look ahead one more
screen line (to determine whether it will still be too long after
wrapping), which will slow down redisplay and complicate the code even
more.

It will also have a nasty (IMO) effect, whereby adding or removing a
character to the "bbb..." part will make the display change between
this:

   aaaaaaaaaaaaaaaa
   bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

and this:

   aaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

This will cause all the rest of the text below this line to scroll up
or down, which will require us to disable several redisplay
optimizations when just one character is inserted/deleted.

If someone can find a clever technique to overcome these difficulties,
I'm sure patches will be very welcome.

> This is also an issue in todo-mode, which by default
> enables visual-line-mode and indents with wrap-prefix.  For example,
> here both items have no space after the date, but the second one is too
> long for the window, so Visual Line mode breaks it:
> 
> 1 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/log/
> 2 [May 31, 2018] 
>    
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c0a0351249c1e6a9307224d
>    8337ff8916f4cf138
> 
> It would be nice if the display could be like this:
> 
> 1 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/log/
> 2 [May 31, 2018] 
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c0a035124
>    9c1e6a9307224d8337ff8916f4cf138

The usual way of handling these situations is to turn on
truncate-lines.  Any reasons why you don't do that in that mode?
Especially since we now have horizontal scrolling of just the current
line?