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: Handling invisible text in bidirectional display Date: Sat, 16 Jan 2010 18:54:58 +0200 Message-ID: <83y6jyat25.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1263660877 6753 80.91.229.12 (16 Jan 2010 16:54:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Jan 2010 16:54:37 +0000 (UTC) Cc: emacs-bidi@gnu.org To: emacs-devel@gnu.org Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Sat Jan 16 17:54:30 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 1NWBuu-0001m3-VU for gnu-emacs-bidi@m.gmane.org; Sat, 16 Jan 2010 17:54:29 +0100 Original-Received: from localhost ([127.0.0.1]:35216 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWBuv-0001F2-VB for gnu-emacs-bidi@m.gmane.org; Sat, 16 Jan 2010 11:54:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NWBuo-0001Ck-RO for emacs-bidi@gnu.org; Sat, 16 Jan 2010 11:54:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NWBuj-00017P-J6 for emacs-bidi@gnu.org; Sat, 16 Jan 2010 11:54:22 -0500 Original-Received: from [199.232.76.173] (port=40857 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWBuj-00017F-Ck; Sat, 16 Jan 2010 11:54:17 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:51589) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NWBui-0005Bd-QI; Sat, 16 Jan 2010 11:54:17 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0KWC00B00MSFJP00@a-mtaout22.012.net.il>; Sat, 16 Jan 2010 18:54:15 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.130.198]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KWC007PPMYE1ZC0@a-mtaout22.012.net.il>; Sat, 16 Jan 2010 18:54:15 +0200 (IST) 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:435 gmane.emacs.devel:120111 Archived-At: This is another design decision I needed to make -- how to handle invisible text in the display engine modified to support bidirectional text. The current unidirectional display code simply skips all the characters that have the invisible property (or are covered by an overlay with such a property). The iteration then resumes at the first character that does not have the invisible property. Thus, Emacs behaves as if the invisible characters simply did not exist in the buffer. But with bidirectional display, the invisible property can begin and/or end in the middle of text that is reordered for display. For example, suppose the buffer includes the following text (capital letters stand for right-to-left characters): abcABCxyz This would normally be displayed like this: abcCBAxyz Now imagine that we have an invisible property on characters C and x. The current code would skip C and x, and stop on y. But because C is encountered when moving backwards from C to A, that causes us to miss A and B entirely and display abcyz which is clearly incorrect. There are additional complications when embedding characters such as RLE and LRO are involved, to override the normal visual order of characters -- in these cases, a suitably placed invisible property can change the visual order of the surrounding visible characters, sometimes in a prominent way. Therefore, I decided to modify the code which skips invisible characters, such that it will skip them in the visual order, until it finds the first character that is outside the region covered by the invisible property. Note that the ``first'' visible character could be before or after the invisible region, in the logical order. This preserves the visual order of displayed characters and does not miss any characters that should be visible, but it does have consequences that are not necessarily trivial. 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 where invisible text is split in two: one after b, the other before x. If ellipsis should be displayed instead of the invisible text, we will now have two places with ellipsis: one instead of c, the other instead of A. To me, these effects seem reasonable. MS Word behaves the same, but it doesn't have the ellipsis feature. And since I'm not aware of any other application except MS Word that supports both bidirectional text and invisible text, I don't know what other reasonable behaviors can be programmed. If someone knows, please tell. Eventually, all this boils down to the question of the use-cases that involve invisible text. If someone can post a list of such use-cases, I could think whether the above modification of the display code will support them. TIA