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: Sat, 10 Oct 2009 20:33:24 +0200 Message-ID: <83fx9rjdzf.fsf@gnu.org> References: <83bpkgl113.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1255199542 1421 80.91.229.12 (10 Oct 2009 18:32:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2009 18:32:22 +0000 (UTC) Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org To: James Cloos Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Sat Oct 10 20:32:13 2009 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 1Mwgjj-0004sM-L4 for gnu-emacs-bidi@m.gmane.org; Sat, 10 Oct 2009 20:32:11 +0200 Original-Received: from localhost ([127.0.0.1]:32774 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mwgjj-0002xj-20 for gnu-emacs-bidi@m.gmane.org; Sat, 10 Oct 2009 14:32:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mwgj6-0002YI-Eh for emacs-bidi@gnu.org; Sat, 10 Oct 2009 14:31:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mwgj5-0002Wh-7D for emacs-bidi@gnu.org; Sat, 10 Oct 2009 14:31:31 -0400 Original-Received: from [199.232.76.173] (port=34235 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mwgj5-0002WX-4E; Sat, 10 Oct 2009 14:31:31 -0400 Original-Received: from mtaout1.012.net.il ([84.95.2.1]:28675) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mwgj4-0006fs-K7; Sat, 10 Oct 2009 14:31:30 -0400 Original-Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KRB001009TQ7O00@i-mtaout1.012.net.il>; Sat, 10 Oct 2009 20:31:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.70.84.229]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KRB007OVA4GQU60@i-mtaout1.012.net.il>; Sat, 10 Oct 2009 20:31:28 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 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:423 gmane.emacs.devel:116074 Archived-At: > From: James Cloos > Cc: emacs-devel@gnu.org, emacs-bidi@gnu.org > > Thanks for posting that. It is a great summary of the concerns and > needs of an editor when dealing with bidi test. Thanks, but I think it's just the beginning. There are lots of other issues to deal with; see, for example, the aspects of search described by Ehud Karni in this thread. The hard problem in making these decisions was to become convinced that all those other issues are reasonably solvable based on these basic features, without actually solving any of them. > Of those points, all but #6 are no brainers; your choices are exactly > what an editor must do. Thanks for confirming that. > Point six is an interesting problem; I'm also unaware of any prior > art. I suspect that in the long term it would be best to note the > start and end directionality of such chunks of text and set them > chunk-by-chunk in a manner similar to how glyphs are set in the > absence of such properties. I think this is impossible in general, because once text is reordered, the information needed to plug in additional chunks (the resolved level of each character) is lost. Note that it is fairly simple to reorder the text of `display' strings together with the surrounding text -- you just need to feed the characters together into the reordering engine. The problem is elsewhere -- in the code that uses the produced glyphs. > But in the short term I agree with the choice you outlined. The future will tell if it was the right decision. Maybe a useful first step to examining its validity would be to prepare a fairly complete list of Emacs applications that currently use the `display' text properties and overlay properties. Given such a list, one could think of their applicability to bidirectional editing, and how the strings should be displayed in each context to do what the users expect.