unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stephen Berman <stephen.berman@gmx.net>
Cc: clement.pitclaudel@live.com, npostavs@gmail.com, 31666@debbugs.gnu.org
Subject: bug#31666: Bad interaction between visual-line-mode and wrap-prefix on long lines
Date: Fri, 01 Jun 2018 10:32:08 +0300	[thread overview]
Message-ID: <834lingdxj.fsf@gnu.org> (raw)
In-Reply-To: <878t7zf0qw.fsf@gmx.net> (message from Stephen Berman on Fri, 01 Jun 2018 09:02:15 +0200)

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





  reply	other threads:[~2018-06-01  7:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-31 12:27 bug#31666: Bad interaction between visual-line-mode and wrap-prefix on long lines Clément Pit-Claudel
2018-05-31 15:06 ` Eli Zaretskii
2018-05-31 23:16   ` Clément Pit-Claudel
2018-06-01  0:19     ` Noam Postavsky
2018-06-01  7:02       ` Stephen Berman
2018-06-01  7:32         ` Eli Zaretskii [this message]
2018-06-01  8:00           ` Stephen Berman
2018-06-01  8:44             ` Eli Zaretskii
2018-06-01  7:36     ` Eli Zaretskii
2018-06-08 18:04       ` Clément Pit-Claudel
2018-06-08 18:32         ` Eli Zaretskii
2018-06-08 19:24           ` Eli Zaretskii
2018-06-08 19:32             ` Clément Pit-Claudel
2018-06-08 21:19           ` Clément Pit-Claudel
2018-06-09  8:42             ` Eli Zaretskii
2018-06-09 12:45               ` Clément Pit-Claudel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=834lingdxj.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=31666@debbugs.gnu.org \
    --cc=clement.pitclaudel@live.com \
    --cc=npostavs@gmail.com \
    --cc=stephen.berman@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).