From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#31666: Bad interaction between visual-line-mode and wrap-prefix on long lines Date: Fri, 01 Jun 2018 10:32:08 +0300 Message-ID: <834lingdxj.fsf@gnu.org> References: <0c50eeb5-7c99-e8ba-2d0b-865b6617cfe1@live.com> <83fu27hnko.fsf@gnu.org> <99baa6b2-584f-789f-ecf8-d845aedd18ef@live.com> <87fu27bboa.fsf@gmail.com> <878t7zf0qw.fsf@gmx.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1527839842 11920 195.159.176.226 (1 Jun 2018 07:57:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Jun 2018 07:57:22 +0000 (UTC) Cc: clement.pitclaudel@live.com, npostavs@gmail.com, 31666@debbugs.gnu.org To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 01 09:57:18 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOew1-000305-N4 for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Jun 2018 09:57:17 +0200 Original-Received: from localhost ([::1]:47974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOey5-0002J9-Re for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Jun 2018 03:59:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOeYc-0006tb-Ro for bug-gnu-emacs@gnu.org; Fri, 01 Jun 2018 03:33:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fOeYY-0001uF-UB for bug-gnu-emacs@gnu.org; Fri, 01 Jun 2018 03:33:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48700) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fOeYY-0001u3-Qy for bug-gnu-emacs@gnu.org; Fri, 01 Jun 2018 03:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fOeYY-00042l-M9 for bug-gnu-emacs@gnu.org; Fri, 01 Jun 2018 03:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Jun 2018 07:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31666 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31666-submit@debbugs.gnu.org id=B31666.152783834415483 (code B ref 31666); Fri, 01 Jun 2018 07:33:02 +0000 Original-Received: (at 31666) by debbugs.gnu.org; 1 Jun 2018 07:32:24 +0000 Original-Received: from localhost ([127.0.0.1]:56596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOeXv-00041e-O3 for submit@debbugs.gnu.org; Fri, 01 Jun 2018 03:32:24 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38760) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOeXs-00041P-EH for 31666@debbugs.gnu.org; Fri, 01 Jun 2018 03:32:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fOeXj-0001IY-D8 for 31666@debbugs.gnu.org; Fri, 01 Jun 2018 03:32:15 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOeXj-0001IU-9h; Fri, 01 Jun 2018 03:32:11 -0400 Original-Received: from [176.228.60.248] (port=3785 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fOeXh-0006fL-Ah; Fri, 01 Jun 2018 03:32:10 -0400 In-reply-to: <878t7zf0qw.fsf@gmx.net> (message from Stephen Berman on Fri, 01 Jun 2018 09:02:15 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:146804 Archived-At: > From: Stephen Berman > Date: Fri, 01 Jun 2018 09:02:15 +0200 > Cc: Clément Pit-Claudel , > 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?