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: Fri, 05 Feb 2010 15:47:37 +0200 Message-ID: <83ock3g5fq.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> <40314.130.55.118.19.1265230948.squirrel@webmail.lanl.gov> <201002041621.o14GL6w5006928@beta.mvs.co.il> <833a1ghjrj.fsf@gnu.org> <201002051221.o15CLmVW016971@beta.mvs.co.il> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1265377778 4070 80.91.229.12 (5 Feb 2010 13:49:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Feb 2010 13:49: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 Fri Feb 05 14:49: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 1NdOYu-0003XQ-OM for gnu-emacs-bidi@m.gmane.org; Fri, 05 Feb 2010 14:49:33 +0100 Original-Received: from localhost ([127.0.0.1]:52262 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NdOYu-0006HX-7v for gnu-emacs-bidi@m.gmane.org; Fri, 05 Feb 2010 08:49:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NdOYK-0005us-HG for emacs-bidi@gnu.org; Fri, 05 Feb 2010 08:48:56 -0500 Original-Received: from [199.232.76.173] (port=47490 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NdOYK-0005uT-3B for emacs-bidi@gnu.org; Fri, 05 Feb 2010 08:48:56 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NdOYI-0000wb-BP for emacs-bidi@gnu.org; Fri, 05 Feb 2010 08:48:55 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:42184) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NdOYH-0000wL-SN; Fri, 05 Feb 2010 08:48:54 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0KXD00D00FI7W000@a-mtaout21.012.net.il>; Fri, 05 Feb 2010 15:47:46 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.70.67.249]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KXD00D5OFNCS710@a-mtaout21.012.net.il>; Fri, 05 Feb 2010 15:47:37 +0200 (IST) In-reply-to: <201002051221.o15CLmVW016971@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:532 gmane.emacs.devel:120940 Archived-At: > Date: Fri, 5 Feb 2010 14:21:49 +0200 > From: "Ehud Karni" > Cc: herring@lanl.gov, emacs-bidi@gnu.org, emacs-devel@gnu.org > > On Thu, 04 Feb 2010 21:40:32 Eli Zaretskii wrote: > > > > Please! Newspapers don't have truncated and continued lines, they > > have newlines between every two lines. With newlines, the bidi > > display will show exactly what you (and every other Hebrew reader) > > expect. > > I think you got it wrong here. Newspaper article are written a whole > paragraph without new lines on a wide screen and then reflowed to > the column width. You can do it with any word processor, and change > the width when you print and get the same behavior. Emacs's way of re-flowing is by inserting newlines. Continuation lines are not it, because they break the line in an arbitrary place, like the middle of a word. This is a no-no in any newspaper article. > I propose the following: use a virtual "right-margin-goal-column" (a > real one if given, and if not it is the screen width), do a virtual > `fill-paragraph' on the line, and do the bidi processing on the > result, BUT without inserting any real new-lines. I explained elsewhere why this does not solve the problem: the reordering code works below the glyph layout code, so it has no idea when it has reached the right-margin-goal-column. At least I don't know how to do that; ideas are welcome. The reordering code can do what you want if we somehow tell it at which _buffer_position_ to stop, as if it hits a newline or a paragraph separator. But buffer positions are not equivalent to display positions, due to display features like: . variable fonts and faces . glyphs that come from overlays, `display' properties, images, etc. . `wrap-prefix' and `line-prefix' variables . composite characters . tab expansion (probably forgot a few). Note that the last one affects text terminals as well, so even there you cannot simply count characters. > It has the shortcoming of not going exactly up to right edge (or left > edge for R2L paragraph), but it will have the benefit of not breaking > words and allowing normal reading for long line with embedding text of > the opposite direction. The problem is that, for the reasons I explain above and in a previous message in this thread, what you suggest will still end up overflowing the margin sometimes, and we are back with the same problem. (If I understood your suggestion, that is; if not, please point out where I'm wrong.)