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: Sat, 16 Jan 2010 22:32:16 +0200 Message-ID: <83wrzhbxkf.fsf@gnu.org> References: <83y6jyat25.fsf@gnu.org> <4B5208E3.7050006@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1263673918 12477 80.91.229.12 (16 Jan 2010 20:31:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Jan 2010 20:31:58 +0000 (UTC) Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Sat Jan 16 21:31:50 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 1NWFJB-00076H-Ga for gnu-emacs-bidi@m.gmane.org; Sat, 16 Jan 2010 21:31:45 +0100 Original-Received: from localhost ([127.0.0.1]:40022 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWFJB-00045u-Ur for gnu-emacs-bidi@m.gmane.org; Sat, 16 Jan 2010 15:31:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NWFJ7-00044y-Ts for emacs-bidi@gnu.org; Sat, 16 Jan 2010 15:31:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NWFJ2-000423-CT for emacs-bidi@gnu.org; Sat, 16 Jan 2010 15:31:40 -0500 Original-Received: from [199.232.76.173] (port=40665 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWFJ2-000420-51; Sat, 16 Jan 2010 15:31:36 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:32966) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NWFJ1-0001OF-OW; Sat, 16 Jan 2010 15:31:35 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0KWC00H00WWOS900@a-mtaout21.012.net.il>; Sat, 16 Jan 2010 22:31:34 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.130.198]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KWC00EVVX0KQW70@a-mtaout21.012.net.il>; Sat, 16 Jan 2010 22:31:34 +0200 (IST) In-reply-to: <4B5208E3.7050006@gmx.at> 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:439 gmane.emacs.devel:120121 Archived-At: > Date: Sat, 16 Jan 2010 19:43:47 +0100 > From: martin rudalics > CC: emacs-devel@gnu.org, emacs-bidi@gnu.org > > But what should we do with overlays with a display property? If you mean how would their characters be reordered for display, I described that in my mail Re: "Bidirectional editing in Emacs -- main design decisions", back in October. I reproduce the relevant excerpt below. If you mean overlays with display properties in some combination with invisible text, please describe the situation in more detail, because I'm not sure I see the difficulty. Here's what I wrote in the mail mentioned above: 6. Reordering of strings from `display' properties Strings that are values of `display' text properties and overlay properties are reordered individually. This matters when such properties cover adjacent portions of buffer text, back to back. For example, PROP1 is associated with buffer positions P1 to P2, and PROP2 immediately follows it, being associated with positions P2 to P3. The current design calls for reordering the characters of the strings that are the values of PROP1 and PROP2 separately. An alternative would be to feed them concatenated into the reordering algorithm, in which case the characters coming from PROP2 could end up displayed before (to the left) of the characters coming from PROP1. However, this alternative requires a major surgery of several parts of the display code. (Interested readers are advised to read the code of set_cursor_from_row in xdisp.c, as just one example.) It's not clear what is TRT to do in this case anyway; I'm not aware of any other application that provides similar features, so there's nothing I could compare it to. So I decided to go with the easier design. If the application needs a single long string, it can always collapse two or more `display' properties into one long one. Another, perhaps more serious implication of this design decision is that strings from `display' properties are reordered separately from the surrounding buffer text. IOW, production of glyphs from reordered buffer text is stopped when a `display' property is found, the string that is the property's value is reordered and displayed, and then the rest of text is reordered and its glyphs produced. The effect will be visible, e.g., when a `display' string is embedded in right-to-left text in otherwise left-to-right paragraph text. Again, I think in the absence of clear "prior art", simplicity of design and the amount of changes required in the existing display engine win here.