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:06:05 +0200 Message-ID: <834omk8sbm.fsf@gnu.org> References: <83y6jyat25.fsf@gnu.org> <4B5208E3.7050006@gmx.at> <83wrzhbxkf.fsf@gnu.org> <4B52D165.40008@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1263755214 11448 80.91.229.12 (17 Jan 2010 19:06:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Jan 2010 19:06:54 +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 Sun Jan 17 20:06:46 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 1NWaST-0007HV-Bl for gnu-emacs-bidi@m.gmane.org; Sun, 17 Jan 2010 20:06:45 +0100 Original-Received: from localhost ([127.0.0.1]:44155 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWaST-0002UV-VU for gnu-emacs-bidi@m.gmane.org; Sun, 17 Jan 2010 14:06:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NWaSS-0002UF-80 for emacs-bidi@gnu.org; Sun, 17 Jan 2010 14:06:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NWaSM-0002Tb-KE for emacs-bidi@gnu.org; Sun, 17 Jan 2010 14:06:42 -0500 Original-Received: from [199.232.76.173] (port=58077 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWaSM-0002TY-6X; Sun, 17 Jan 2010 14:06:38 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:33576) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NWaSL-0002Lj-HO; Sun, 17 Jan 2010 14:06:37 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0KWE00L00NJADG00@a-mtaout22.012.net.il>; Sun, 17 Jan 2010 21:06:05 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.130.198]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KWE00KJSNQ47Y40@a-mtaout22.012.net.il>; Sun, 17 Jan 2010 21:06:05 +0200 (IST) In-reply-to: <4B52D165.40008@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:446 gmane.emacs.devel:120172 Archived-At: > Date: Sun, 17 Jan 2010 09:59:17 +0100 > From: martin rudalics > CC: emacs-devel@gnu.org, emacs-bidi@gnu.org > > > abcABCxyz > > Suppose I put an overlay from the position between "b" and "c" to the > position between "A" and "B" (just like your invisibility property) and > give that overlay a display property, say the character "D". > > > This would normally be displayed like this: > > > > abcCBAxyz > > Should we now see "abDxyz", "abDAxyz", "abDCBDxyz", or something else? "abDCBxyz", I believe. c and A are displayed as D, but the rest of the characters should be visible. > Note that the "D" is quite similar to the ellipses for invisible text > you mentioned earlier. No, it's different. The ellipsis shows that some text is hidden, so if we have several stretches of hidden text, it is reasonable to show an ellipsis for each stretch. By contrast, a display property says, in effect, to display the string _instead_ of the entire text covered by the overlay, so it should be displayed only once. > BTW, I'm not even sure whether > > > 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. > > _is_ "clearly incorrect". Conversely, suppose I have the displayed text > > abcCBAxyz > > with `point' between "b" and "c" and `mark' between "C" and "B" - no > overlays or text properties involved. When I now kill the region what > will show up on the kill ring - "cAB" or "cC"? I didn't introduce a ``visual-order'' killing, so text is still killed in the logical order. Therefore, the characters that will be killed and appear in the kill ring are cAB (displayed as "cBA"), and the resulting display after killing will be "abCxyz". Makes sense?