From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel,gmane.emacs.bidi Subject: Re: Bidirectional editing in Emacs -- main design decisions Date: Sat, 10 Oct 2009 18:06:47 +0200 Message-ID: <83my3zjkrs.fsf@gnu.org> References: <83bpkgl113.fsf@gnu.org> <4AD0A4AC.8010202@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1255190939 10612 80.91.229.12 (10 Oct 2009 16:08:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2009 16:08:59 +0000 (UTC) Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org To: Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 10 18:08:50 2009 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 1MweUw-0001yb-TK for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2009 18:08:50 +0200 Original-Received: from localhost ([127.0.0.1]:41614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MweUu-0007EN-S3 for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2009 12:08:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MweRO-0001ht-W4 for emacs-devel@gnu.org; Sat, 10 Oct 2009 12:05:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MweRO-0001ga-4q for emacs-devel@gnu.org; Sat, 10 Oct 2009 12:05:06 -0400 Original-Received: from [199.232.76.173] (port=46633 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MweRM-0001dA-4I; Sat, 10 Oct 2009 12:05:04 -0400 Original-Received: from mtaout5.012.net.il ([84.95.2.13]:27293) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MweRD-0008PW-3n; Sat, 10 Oct 2009 12:04:55 -0400 Original-Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KRB00I003A3P500@i_mtaout5.012.net.il>; Sat, 10 Oct 2009 18:04:51 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.70.84.229]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KRB00EHH3C35Y41@i_mtaout5.012.net.il>; Sat, 10 Oct 2009 18:04:51 +0200 (IST) In-reply-to: <4AD0A4AC.8010202@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 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:116070 gmane.emacs.bidi:419 Archived-At: > Date: Sat, 10 Oct 2009 23:13:48 +0800 > From: Jason Rumney > CC: emacs-devel@gnu.org, emacs-bidi@gnu.org > > Eli Zaretskii wrote: > > 4. Reordering of text for display > > > > Does the function font-shape-gstring help with fitting this in? I'm sorry to say that I don't understand what it does. If you can explain, or give me an educational example to play with, maybe I will be able to answer your question, my profound ignorance of GUI rendering notwithstanding. > > 8. User control of visual order > > > > I decided it was unjustified to deviate from UAX#9. Its algorithm > > already provides the solution to this problem: users can always > > control the visual order by inserting special formatting codes at > > strategic places. > > Couldn't Emacs by default use the clever heuristics to decide when to > automatically insert the special formatting codes? It would have to be > optional and undoable of course, because heuristics are never perfect, > but it seems to me as a naive non-speaker of RTL languages that to DWIM > in these edge cases is the right behaviour. I agree: if it's possible to DWIM automatically, we should. But you are talking about higher levels than where I am right now. For my purposes, it was good enough to decide that any such clever heuristics will eventually just add or remove formatting codes, and that no other infrastructure features are needed to support this. > Also you mention several times that the special direction change codes > are not displayed, but there should be an option to display them IMHO, > (perhaps part of whitespace.el) as users may need to distinguish between > explicit direction changes and implicit ones in some circumstances. Yes, that's a very important feature, of course. Which is why I tried (but obviously failed, since you are the second person asking the same) to tell that it will and must be supported: In addition, being able to show these formatting codes to the user is a valuable feature, because the way reordered text looks might not be otherwise understood or changed easily.