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: Handling invisible text in bidirectional display Date: Sun, 17 Jan 2010 21:29:33 +0200 Message-ID: <833a248r8i.fsf@gnu.org> References: <83y6jyat25.fsf@gnu.org> <87eilpzwrs.fsf@lola.goethe.zz> <83vdf1bxbg.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1263756680 15942 80.91.229.12 (17 Jan 2010 19:31:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Jan 2010 19:31:20 +0000 (UTC) Cc: emacs-bidi@gnu.org, dak@gnu.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Sun Jan 17 20:31:12 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.50) id 1NWaq7-00084u-1J for gnu-emacs-bidi@m.gmane.org; Sun, 17 Jan 2010 20:31:11 +0100 Original-Received: from localhost ([127.0.0.1]:35300 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWaq7-0004WD-Mb for gnu-emacs-bidi@m.gmane.org; Sun, 17 Jan 2010 14:31:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NWapI-00045K-MQ for emacs-bidi@gnu.org; Sun, 17 Jan 2010 14:30:20 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NWapE-00041U-0l for emacs-bidi@gnu.org; Sun, 17 Jan 2010 14:30:20 -0500 Original-Received: from [199.232.76.173] (port=54945 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWapD-00041Q-To; Sun, 17 Jan 2010 14:30:15 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:58194) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NWapA-0007nL-80; Sun, 17 Jan 2010 14:30:12 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0KWE00200OMGP900@a-mtaout20.012.net.il>; Sun, 17 Jan 2010 21:29:34 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.130.198]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KWE00I66OT80VQ0@a-mtaout20.012.net.il>; Sun, 17 Jan 2010 21:29:33 +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:447 gmane.emacs.devel:120173 Archived-At: > From: Richard Stallman > CC: dak@gnu.org, emacs-bidi@gnu.org, emacs-devel@gnu.org > Date: Sun, 17 Jan 2010 11:05:03 -0500 > > Your description of the interaction of invisible with bidi seems right > to me, but I was surprised by your response to this > > > I think a reasonable model is to display the text as if the invisible > > characters are not there. > > I think the resulting change of the visual order will surprise the > users. It also complicates implementation, which for me is an > important downside. > > because I don't see a differnce between "display the text as if the > invisible characters are not there" and what you described (in the > no-ellipsis case). What you described > > One consequence is that a run of invisible characters can now be split > into several non-contiguous runs. For example, this text: > > abcABCxyz > > with c and A covered by an invisible property will be displayed as > > abCBxyz > > seems to agree entirely with that description. Is there something I > have misunderstood? It's just that the example I showed is a simple one, where the distinction doesn't show. However, in general, the bidirectional reordering can cause simple insertion to have non-local effect on the visual order. This is because so-called weak characters (digits, plus, minus, punctuation, etc.) and neutral characters (blanks, tabs, etc.) change their directionality depending on the surrounding text. Here's an example. Suppose the buffer contains this text: ABCD(4+5)*3 (As usual, capital letters are strong right-to-left characters.) This text will be displayed as 3*(5+4)DCBA By contrast, the same text with `+' removed will display as 3*(45)DCBA As you see, 4 and 5 switched their visual order. This means that if we first remove the invisible characters and then reorder, the 4 and 5 will appear in a different order when `+' is invisible than when it is visible. With my suggestion, we _first_ reorder and _then_ hide invisible characters, so the display with `+' invisible will be 3*(54)DCBA which I think is less surprising.