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: improving bidi documents display Date: Fri, 04 Mar 2011 11:52:28 +0200 Message-ID: <83lj0vi55v.fsf@gnu.org> References: <837hcpryxr.fsf@gnu.org> <87wrklpzii.fsf@maru.md5i.com> <83aahhnpr3.fsf@gnu.org> <4D6DA6E6.70509@it.aoyama.ac.jp> <87zkpe9rfp.fsf@catnip.gol.com> <83k4gixj6m.fsf@gnu.org> <83aahdxt74.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1299232485 25211 80.91.229.12 (4 Mar 2011 09:54:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 4 Mar 2011 09:54:45 +0000 (UTC) Cc: eli.osherovich@gmail.com, md5i@md5i.com, emacs-bidi@gnu.org, emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Fri Mar 04 10:54:38 2011 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 1PvRiY-0007Ki-CX for gnu-emacs-bidi@m.gmane.org; Fri, 04 Mar 2011 10:54:38 +0100 Original-Received: from localhost ([127.0.0.1]:47085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PvRiX-0001QY-Vz for gnu-emacs-bidi@m.gmane.org; Fri, 04 Mar 2011 04:54:38 -0500 Original-Received: from [140.186.70.92] (port=47970 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PvRiT-0001OV-MV for emacs-bidi@gnu.org; Fri, 04 Mar 2011 04:54:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PvRiS-0000ez-5k for emacs-bidi@gnu.org; Fri, 04 Mar 2011 04:54:33 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:55552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PvRiR-0000em-TC; Fri, 04 Mar 2011 04:54:32 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LHJ00L002469W00@a-mtaout23.012.net.il>; Fri, 04 Mar 2011 11:54:30 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.183.216]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LHJ00KDP26SZ460@a-mtaout23.012.net.il>; Fri, 04 Mar 2011 11:54:30 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.175 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:864 gmane.emacs.devel:136754 Archived-At: > From: Miles Bader > Cc: eli.osherovich@gmail.com, md5i@md5i.com, emacs-bidi@gnu.org, > emacs-devel@gnu.org > Date: Fri, 04 Mar 2011 13:25:17 +0900 > > Eli Zaretskii writes: > > This one's different, believe me: no other text property changes the > > _order_ of characters on display in creative ways. It could easily > > render the text illegible, under just the right circumstances. Other > > text properties are either non-intrusive, or are almost immediately > > fixed by JIT Lock, or are simply rare enough to not get in our way. > > This one, if used to implement partial reordering of buffer text, will > > be ubiquitous in any buffer with program sources that include bidi > > comments and strings, i.e. we will see it _a_lot_. > > I'm a bit confused by how an ordering that's "good" in (e.g.) a TeX > document, would be "illegible" in another context... > > Can you give an example of such a case? Not really, since we are talking about an idea, not about a feature that has a detailed design which we could reason about. Any example I give can be countermanded by saying something like "but if we implement the idea such and such, then this particular problem won't happen". I can, however, show you why I'm afraid of leaving the "reordering" properties on the text. The reason is that the visual results of reordering are highly context-dependent. Changing a single character very far away from the locus of reordering can completely change the visual appearance of an unrelated portion of text. You can try the below in Emacs 24, after setting bidi-display-reordering non-nil (but be sure to do that in a buffer other than *scratch* or any other buffer whose major mode is programming-language oriented, because these are forced to have a left-to-right paragraph direction). Here's an example. Type this text, left to right: abcdef \foo{ABCDEF} xyz (As usual, lower-case letters are Latin, upper-case are in some R2L script, such as Arabic or Hebrew.) The above will be displayed like this: abcdef \foo{FEDCBA} xyz So far so good, right? And looks "good" in a TeX document, right? Now go to the beginning of the line (C-a) and type a single R2L letter (W). The resulting display will change dramatically: xyz {FEDCBA}abcdef \fooW The reason, in this case, for such a significant change is that directionality of the first character of a paragraph determines the "base direction" of that paragraph. (Actually, only "strong directional characters" count, those which have "L" or "R" bidi category in the Unicode data base.) There are other examples, but the underlying reason is the same: bidi reordering is highly dependent on the surrounding context. Copy a region of text to another context, and you might have undesirable results. If these results are due to characters that are part of the buffer text (as in the above example), one can cope with that by editing after the yank. But if the results are due to some invisible factor like text properties, this is tougher on users. That is why I prefer that these invisible factors not be copied with the text. If needed, they will be re-applied according to the rules of the target buffer.