From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel,gmane.emacs.bidi Subject: Re: Handling invisible text in bidirectional display Date: Sun, 17 Jan 2010 09:59:17 +0100 Message-ID: <4B52D165.40008@gmx.at> References: <83y6jyat25.fsf@gnu.org> <4B5208E3.7050006@gmx.at> <83wrzhbxkf.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1263718777 8443 80.91.229.12 (17 Jan 2010 08:59:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Jan 2010 08:59:37 +0000 (UTC) Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 17 09:59:29 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NWQyn-0002h6-6h for ged-emacs-devel@m.gmane.org; Sun, 17 Jan 2010 09:59:29 +0100 Original-Received: from localhost ([127.0.0.1]:57557 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWQyo-0006f1-0y for ged-emacs-devel@m.gmane.org; Sun, 17 Jan 2010 03:59:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NWQyi-0006eu-Um for emacs-devel@gnu.org; Sun, 17 Jan 2010 03:59:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NWQye-0006eQ-Vu for emacs-devel@gnu.org; Sun, 17 Jan 2010 03:59:24 -0500 Original-Received: from [199.232.76.173] (port=56596 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWQye-0006eF-LS for emacs-devel@gnu.org; Sun, 17 Jan 2010 03:59:20 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]:33860) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NWQye-0007ye-0A for emacs-devel@gnu.org; Sun, 17 Jan 2010 03:59:20 -0500 Original-Received: (qmail invoked by alias); 17 Jan 2010 08:59:18 -0000 Original-Received: from 62-47-45-165.adsl.highway.telekom.at (EHLO [62.47.45.165]) [62.47.45.165] by mail.gmx.net (mp008) with SMTP; 17 Jan 2010 09:59:18 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18nXUUP/Rwn+bovpLhh08wz/Bb56P2UGOKjoD0Wnx DUG8Y1t0kDYF5Q User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <83wrzhbxkf.fsf@gnu.org> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65000000000000002 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:120138 gmane.emacs.bidi:442 Archived-At: > 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. I meant neither of them. From your initial example: > For example, suppose the buffer includes the following text (capital > letters stand for right-to-left characters): > > 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? Note that the "D" is quite similar to the ellipses for invisible text you mentioned earlier. This issue is obviously not very important - after all an overlay is probably misplaced if its start and end are in text displayed in different directions - but would have to be solved somehow anyway. 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"? martin