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 11:50:58 +0200 Message-ID: <83tytwf1tp.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1265365901 16738 80.91.229.12 (5 Feb 2010 10:31:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Feb 2010 10:31:41 +0000 (UTC) Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Fri Feb 05 11:31:38 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 1NdLTH-00032G-94 for gnu-emacs-bidi@m.gmane.org; Fri, 05 Feb 2010 11:31:31 +0100 Original-Received: from localhost ([127.0.0.1]:60855 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NdKrU-0006qQ-8N for gnu-emacs-bidi@m.gmane.org; Fri, 05 Feb 2010 04:52:28 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NdKrK-0006po-EJ for emacs-bidi@gnu.org; Fri, 05 Feb 2010 04:52:18 -0500 Original-Received: from [199.232.76.173] (port=54895 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NdKrJ-0006pS-OV for emacs-bidi@gnu.org; Fri, 05 Feb 2010 04:52:17 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NdKrH-0005OZ-Bm for emacs-bidi@gnu.org; Fri, 05 Feb 2010 04:52:17 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:54906) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NdKrG-0005OV-Ln; Fri, 05 Feb 2010 04:52:15 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0KXD008004KUPB00@a-mtaout22.012.net.il>; Fri, 05 Feb 2010 11:50:59 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.70.67.249]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KXD0085L4OXS100@a-mtaout22.012.net.il>; Fri, 05 Feb 2010 11:50:59 +0200 (IST) In-reply-to: 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:527 gmane.emacs.devel:120927 Archived-At: > From: Stefan Monnier > Cc: ehud@unix.mvs.co.il, emacs-bidi@gnu.org, emacs-devel@gnu.org > Date: Thu, 04 Feb 2010 17:13:29 -0500 > > >> This how it is done in Hebrew newspapers and in HTML, and this is how > >> Hebrew readers are used to it (of course newspapers and HTML don't > >> breaks words, but that is the only difference). > > 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'm not sure whether newpapers really have such newlines (at least for > paper newspapers, it's a philosophical question). But I think Ehud's > argument makes sense if you consider that currently (i.e. in L2R only > text), adding a newline where Emacs wraps a line, leads to "the same > display" (modulo line-wrapping glyphs in the fringe and things like > that, obviously). And I understand Ehud's argument as saying that the > same should hold for R2L and mixed text. > > It seems at least a reasonable point of view. Is your point of view > based on the fact that it seems difficult/impossible to implement, or is > it based on the fact that you think Ehud's expectation is weird? I'm sorry I didn't make myself clear enough on that, to the degree that such a question should at all be asked. Like Ehud, I think that it would be swell to have what he wants. But, possibly unlike Ehud, I think that what I have now it not a disaster, and we can live with it for the time being, maybe even longer. The reasons for my decision to implement truncation and continuation as I did are: . It is the only reasonable way to go that does not call for a very serious surgery, perhaps even a total rewrite, of the display engine code. . I saw no other editor that supports truncation and behaves otherwise. (I don't know about any editors that support continuation lines like Emacs does.) See below. . The issue pops up only in relatively rare situations: mixed L2R/R2L text that gets truncated/continued within a stretch of text whose directionality is against the paragraph direction. > If it's just "difficult", then (just like rigid scrolling), it can be > kept as a known shortcoming. It is either VERY difficult or very slow. The current display code lays out glyphs in each ``glyph row'' one by one, in the visual order. Thus, for the portion of text that is reversed from its logical order, the bidi reordering code effectively delivers the characters backwards to this glyph layout code, in the decreasing order of buffer positions. That is, the glyphs assembled first are the last ones to be read. Then you hit the window margin, and know that there isn't enough place for the whole line. Only then you know how many characters will fit on this line. But you know that in terms of the last portion of the text in the reading order, which tells you very little about how many characters at the beginning of this stretch of text you could display instead. (Remember that Emacs supports variable size characters and different fonts on the same line, so just counting characters will not do.) What would be nice is to scan the text to be reversed in the logical order, and find the part of it that will fit on this screen line. Then we could reorder only that part. But to do that, we need to try every possibility by actually doing most of the display work behind the scenes, because of the complications with different font sizes, faces, composite characters and issues like ligatures and the like, which change the amount of screen estate taken by a portion of a line, even if you just juxtapose the same two characters. With a newline marking the end of the line, it's easy: the bidi reordering ends at the newline, then restarts after it. By contrast, to support ``bidi-smart continuation'', we need to find the place where to break the line, and that is impossible without actually trying to display it. In the example below word1 word2 WORD1 WORD2 to be displayed as word1 word2 2DROW 1DROW if the window is only wide enough to display word1 word2 1DROW we need to try displaying in order word1 word2 1 word1 word2 1D word1 word2 1DR word1 word2 1DRO word1 word2 1DROW word1 word2 1DROW word1 word2 W 1DROW until we discover where we should stop. (We could do a binary search, of course, but that's details.) I don't think that's reasonable, and I have no idea what will this do to the redisplay speed. > How do other line-wrapping text editors with bidi support behave with > such long mixed-L2R-R2L lines? MS Word truncates in the visual order, like I suggest. It doesn't have continuation lines (it re-flows instead, which is the same as our fill-paragraph, and that works like Ehud wants already.) I didn't have a chance of checking OpenOffice; I can do that next week, if no one beats me to it. I have Yudit installed, but I cannot get it to display Hebrew text (it shows hex numbers instead); if someone knows how to do that on Windows, please tell. But someone told in this thread that it, too, re-flows. If that's true, we have no prior art that's different from what I have now in the bidi Emacs. Of course, Emacs breaks ground where many other similar tools punt...