From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bidi,gmane.emacs.devel Subject: Re: Mixed L2R and R2L paragraphs and horizontal scroll Date: Thu, 04 Feb 2010 21:30:10 +0200 Message-ID: <83636chk8t.fsf@gnu.org> References: <83tyu3iu6b.fsf@gnu.org> <201002011400.o11E0jMQ007420@beta.mvs.co.il> <83vdeghfqg.fsf@gnu.org> <201002012205.o11M5Sci011809@beta.mvs.co.il> <83k4uvh09o.fsf@gnu.org> <201002031310.o13DAqXd019253@beta.mvs.co.il> <83eil2gn7i.fsf@gnu.org> <201002041402.o14E2wQ0024776@beta.mvs.co.il> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1265311838 6084 80.91.229.12 (4 Feb 2010 19:30:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2010 19:30:38 +0000 (UTC) Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org To: ehud@unix.mvs.co.il Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Thu Feb 04 20:30:35 2010 Return-path: Envelope-to: gnu-emacs-bidi@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nd7PN-0007St-QU for gnu-emacs-bidi@m.gmane.org; Thu, 04 Feb 2010 20:30:34 +0100 Original-Received: from localhost ([127.0.0.1]:39481 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nd7PN-0007hw-2v for gnu-emacs-bidi@m.gmane.org; Thu, 04 Feb 2010 14:30:33 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nd7PI-0007hG-DV for emacs-bidi@gnu.org; Thu, 04 Feb 2010 14:30:28 -0500 Original-Received: from [199.232.76.173] (port=56647 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nd7PI-0007h2-43 for emacs-bidi@gnu.org; Thu, 04 Feb 2010 14:30:28 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nd7PG-0004Dm-DW for emacs-bidi@gnu.org; Thu, 04 Feb 2010 14:30:28 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:55214) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nd7PG-0004De-1G; Thu, 04 Feb 2010 14:30:26 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0KXB00F00ZT08K00@a-mtaout20.012.net.il>; Thu, 04 Feb 2010 21:30:11 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.70.67.249]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KXC008I00UAK7D0@a-mtaout20.012.net.il>; Thu, 04 Feb 2010 21:30:11 +0200 (IST) In-reply-to: <201002041402.o14E2wQ0024776@beta.mvs.co.il> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-bidi@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of Emacs support for multi-directional text." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Errors-To: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bidi:519 gmane.emacs.devel:120915 Archived-At: > Date: Thu, 4 Feb 2010 16:02:58 +0200 > From: "Ehud Karni" > Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org > > On Wed, 03 Feb 2010 20:59:13 Eli Zaretskii wrote: > > > > Maybe you are talking about how lines are re-flowed by these word > > processors. If so, the Emacs equivalent is fill-paragraph, or the > > various packages (like longlines) that do it automatically for you. > > When a line is filled, a newline is inserted, and then the order of > > the text spread between several lines is what you expect: > > OK, I want it to work like fill-paragraph, but I don't want to REALLY > do fill-paragraph, because I don't want to modify the file AT ALL. Right, and I want $5 million on my bank account, but it doesn't happen ;-) Look, as you know, the bidirectional display reorders on the buffer text level, not on the glyph level. This means that in this example: name2 1234 catag2 NOITPIRCSED-GNOL-YREV name3 when the display engine, marching from left to right, reaches the beginning of the R2L text (the character N), and calls the bidi reordering code, that code runs all the way to just before "name3", then starts delivering the characters backwards, from right to left. This ``run to the end of R2L text'' happens below the level that produces glyphs for display. Therefore, the code which does this run has no idea where the visible part of the line ends. If it bumps into a newline, it stops and goes backward, which is why filling a paragraph displays like you expect. But to do what you want in a truncated or continued line means I need to throw away the entire design and implementation of the bidi reordering. I think it's too heavy price to pay for a relatively rare situation (mixed L2R and R2L text that hits the window margin at the wrong place). > From experience (with my visual Hebrew package) this is very annoying. > Think of 3 very long (150, 270 and 150 characters) viewed on 80 > characters wide screen, It is very confusing to find the start of > each line and to read upward 1 or 2 lines and go down again. Again, _only_ if these long lines mix R2L and L2R, and then _only_ if the text that crosses the 80-column border has its direction against the base paragraph direction. > > > Oops, the beginning of the Hebrew text disappeared. > > > > And this is significantly worse than if the _end_ of the text > > disappears, because...? > > Yes, it is definitely worse. First the the case of text that goes just > a screen and half down. You'll have to scroll one page down, read a > few lines upward, that scroll up, find the last line you read and > continue upward, you may need scroll up once more for the beginning of > the text. Second, consider the case of a very, very long text (more > than 100 continuation lines), it is almost impossible to find its > start with your way, while in my way it is just the normal way of > scrolling down (I do it by half screen at a time). Maybe you forgot that we have line-move-visual since Emacs 23.1. Anyway, I agree that for any limitation it's possible to find a use-case, however marginal, where that limitation will be very annoying. (Yes, I think that 100 continuation lines, all of them having R2L text when the paragraph is L2R, is a rare case.) > I don't think this issue is problematic per se. I think that if the > solution for R2L scrolling is good (when all the paragraphs are R2L) > then it can be applied even when combined with L2R paragraphs on the > same screen without any annoyance to the user. Thanks. Then help me convince Richard ;-)