From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#2749: 23.0.91; Visual Line Mode: incorrect line wrapping in corner case Date: Fri, 10 May 2013 16:01:22 +0200 Message-ID: <871u9f6ij1.fsf@rosalinde.fritz.box> References: <87d4c694r2.fsf@cyd.mit.edu> <87obfhhn9d.fsf@rosalinde.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1368194526 3364 80.91.229.3 (10 May 2013 14:02:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 May 2013 14:02:06 +0000 (UTC) Cc: pent , 2749@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 10 16:02:04 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Uantc-0005oa-3Y for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 May 2013 16:02:04 +0200 Original-Received: from localhost ([::1]:35973 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uanta-00071Y-4y for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 May 2013 10:02:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UantT-0006wy-Sg for bug-gnu-emacs@gnu.org; Fri, 10 May 2013 10:01:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UantQ-0003mj-RZ for bug-gnu-emacs@gnu.org; Fri, 10 May 2013 10:01:55 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UantQ-0003mf-OU for bug-gnu-emacs@gnu.org; Fri, 10 May 2013 10:01:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Uanta-0004Z8-N4 for bug-gnu-emacs@gnu.org; Fri, 10 May 2013 10:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 May 2013 14:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 2749 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 2749-submit@debbugs.gnu.org id=B2749.136819450617514 (code B ref 2749); Fri, 10 May 2013 14:02:02 +0000 Original-Received: (at 2749) by debbugs.gnu.org; 10 May 2013 14:01:46 +0000 Original-Received: from localhost ([127.0.0.1]:35703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UantH-0004YK-Pl for submit@debbugs.gnu.org; Fri, 10 May 2013 10:01:45 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:57412) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UantB-0004Xe-Fi for 2749@debbugs.gnu.org; Fri, 10 May 2013 10:01:39 -0400 Original-Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LosgX-1U4T4Y41Rj-00gm8o for <2749@debbugs.gnu.org>; Fri, 10 May 2013 16:01:25 +0200 Original-Received: (qmail invoked by alias); 10 May 2013 14:01:25 -0000 Original-Received: from i59F57249.versanet.de (EHLO rosalinde.fritz.box) [89.245.114.73] by mail.gmx.net (mp029) with SMTP; 10 May 2013 16:01:25 +0200 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX19lZzdV2HRlO8RN0xxVuEEmUZkw1kKQoMNg4fz6Am 0jjrzlknwYs2gs In-Reply-To: <87obfhhn9d.fsf@rosalinde.fritz.box> (Stephen Berman's message of "Mon, 18 Feb 2013 12:31:10 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:74124 Archived-At: On Mon, 18 Feb 2013 12:31:10 +0100 Stephen Berman wrote: > On Tue, 24 Mar 2009 21:35:02 -0400 Stefan Monnier wrote: > >>> This behavior is expected. The word wrap algorithm treats lines that >>> are too long to wrap using the ordinary line-wrapping rules, and since >>> overflow-newline-into-fringe is disabled in Visual Line mode, the extra >>> empty line is used to show the non-overflowed newline character. >> >>> After the release, I might look into letting word wrap handle >>> overflow-newline-into-fringe behavior. I suspect, however, that this >>> may lead to confusing results in some circumstances. >> >> BTW: why is overflow-newline-into-fringe ignored when word-wrap is >> non-nil? What kind of confusing results are you thinking of? > > I would like to use a string of length window-width in a display overlay > together with word-wrap and a non-nil wrap-prefix. Currently this > results in a following empty line with indentation, which is rather > disconcerting. But after removing `&& (IT)->line_wrap != WORD_WRAP' > from the definition of IT_OVERFLOW_NEWLINE_INTO_FRINGE and rebuilding > Emacs, the empty indented line is gone and I have just what I want. I > haven't yet seen anything confusing. So I too would be very interested > to know if there are known or suspected problems with allowing non-nil > overflow-newline-into-fringe with word-wrap. If it's not clear there > are any, could we allow it and then see if anyone screams bloody murder? I've been using Emacs as described above (i.e., with the patch below) and till today have had no problems, but I just bumped into one, which is indeed confusing, even pretty nasty. I've reproduced it with -Q on a fresh build from the latest trunk (with the patch added). I don't know how to debug it, but I will describe how to reproduce it, in the hope that someone can fix it (or at least give me some help in trying to debug it) and then hopefully overflow-newline-into-fringe can be allowed in Visual Line mode. Here's the recipe: -1. Apply the following patch and rebuild Emacs: *** /home/steve/bzr/emacs/trunk/src/xdisp.c 2013-05-10 12:51:51.000000000 +0200 --- /home/steve/bzr/emacs/quickfixes/src/xdisp.c 2013-05-10 14:56:22.000000000 +0200 *************** *** 378,385 **** && ((IT)->bidi_it.paragraph_dir == R2L \ ? (WINDOW_LEFT_FRINGE_WIDTH ((IT)->w) > 0) \ : (WINDOW_RIGHT_FRINGE_WIDTH ((IT)->w) > 0)) \ ! && (IT)->current_x == (IT)->last_visible_x \ ! && (IT)->line_wrap != WORD_WRAP) #else /* !HAVE_WINDOW_SYSTEM */ #define IT_OVERFLOW_NEWLINE_INTO_FRINGE(it) 0 --- 378,384 ---- && ((IT)->bidi_it.paragraph_dir == R2L \ ? (WINDOW_LEFT_FRINGE_WIDTH ((IT)->w) > 0) \ : (WINDOW_RIGHT_FRINGE_WIDTH ((IT)->w) > 0)) \ ! && (IT)->current_x == (IT)->last_visible_x) #else /* !HAVE_WINDOW_SYSTEM */ #define IT_OVERFLOW_NEWLINE_INTO_FRINGE(it) 0 0. emacs -Q 1. Type `C-u 69 x SPC C-u 10 x' to make a string of 69 x's followed by a space followed by a string of 10 x's; point should be in the fringe. 2. Type `RET C-u 69 x RET C-u 69 x' to add two more lines 69 x's long (this is not essential to show the bug but helps in describing its effects). 3. M-x visual-line-mode; now the string of 10 x's in the first line has wrapped to occupy its own visual line below the first string of x's, i.e., you see a line of 69 x's followed by a line of 10 x's followed by two more lines of 69 x's. 4. If you click with the mouse (which button doesn't matter, but mouse-1 is least intrusive) anywhere in the buffer up to and including the space following the last x in the first line of x's, point is set where you click, as usual. Now come the confusing results. 5. If you click with the mouse on the first column after the space at the end of the first line of x's, point is set on the first x of the following word-wrap line; if you click on the second column after the space, point is set on the second x below, and so on up to the fringe in the first line of x's. 6. If you click with the mouse on any position starting with the first x in the second, visual, line (the word-wrapped line), point is set one line below in the same column. The goes for all following lines in the buffer, even if not word-wrapped (actually, with further word-wrapping below the first word-wrapped line, I've seen point being set two lines below, but it's harder to reproduce that). 7. If you put point (using the keyboard, whose events are not effected by this bug) somewhere on the second line of 69 x's (the one just below the word-wrapped line of 10 x's) and then type `C-l' twice to move that line to the top of the window, now clicking with the mouse anywhere on this line or lower again correctly sets point where you click. If you scroll vertically so that the word-wrapped line is again visible in the window, the point setting problem happens again. 8. If you add one character to the first line of x's, thus making its (unwrapped) length longer than window-width, the point setting problem does not happen.