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: Bidirectional editing in Emacs -- main design decisions Date: Mon, 18 Apr 2011 17:54:50 +0300 Message-ID: <8362qbsj7p.fsf@gnu.org> References: <83bpkgl113.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1303138513 20417 80.91.229.12 (18 Apr 2011 14:55:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Apr 2011 14:55:13 +0000 (UTC) To: emacs-devel@gnu.org, emacs-bidi@gnu.org Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Mon Apr 18 16:55:09 2011 Return-path: Envelope-to: gnu-emacs-bidi@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QBpr3-0007Zi-1L for gnu-emacs-bidi@m.gmane.org; Mon, 18 Apr 2011 16:55:09 +0200 Original-Received: from localhost ([::1]:51704 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QBpr2-0004IE-CI for gnu-emacs-bidi@m.gmane.org; Mon, 18 Apr 2011 10:55:08 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46535) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QBpqz-0004Hy-V5 for emacs-bidi@gnu.org; Mon, 18 Apr 2011 10:55:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QBpqu-0007bE-7F for emacs-bidi@gnu.org; Mon, 18 Apr 2011 10:55:05 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:50432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QBpqt-0007bA-Tu; Mon, 18 Apr 2011 10:55:00 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LJU00900RTGJQ00@a-mtaout23.012.net.il>; Mon, 18 Apr 2011 17:54:58 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.124.96.168]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LJU009ZDS3KB960@a-mtaout23.012.net.il>; Mon, 18 Apr 2011 17:54:58 +0300 (IDT) In-reply-to: <83bpkgl113.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.175 X-BeenThere: emacs-bidi@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of Emacs support for multi-directional text." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Original-Sender: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bidi:867 gmane.emacs.devel:138553 Archived-At: > Date: Fri, 09 Oct 2009 23:18:00 +0200 > From: Eli Zaretskii > Cc: > > While there's a lot of turf to be covered yet, I thought I'd publish > the main design decisions up to this point. I don't know if someone follows these design decisions, but in case people are interested, here's an update: > 6. Reordering of strings from `display' properties > ... > 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. After careful thought, I changed my mind about this part. Whenever the redisplay iterator finds text that is covered by a `display' text property or by an overlay with a `display', `before-string', or `after-string' property, it will not stop reordering. Instead, it will treat the entire run of text covered by the text property or overlay as a single atomic entity, and will reorder it as if it were a single special character whose name in Unicode is OBJECT REPLACEMENT CHARACTER (u+FFFC). This character's bidirectional category (Other Neutral) and other properties are designed so that it can stand for display features such as embedded images, and in particular it is reordered as appropriate for such embedded objects. This will reorder images and display strings in the same way wrt surrounding text, which I think is reasonable. It is also in line with the pre-Emacs 24 unidirectional display engine, which skipped the text covered by such properties in one go, after displaying the image or a display string specified by the property. I hope this is the last "main design decision" regarding the basic bidirectional display. Barring any unexpected events, I will soon begin implementing reordering of display strings and images, and what will be left is "just" debugging. What will remain in the design department after that is bidirectional display in buffers that are not plain text: program source files (where bidirectional scripts can be found in strings and comments) and markup languages such as HTML and XML.