From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Fri, 26 Aug 2011 22:53:36 -0400 Message-ID: References: <4E48D309.6050503@acdlabs.ru> <83hb5jujjs.fsf@gnu.org> <874o1j10zv.fsf@fencepost.gnu.org> <8362lyvcli.fsf@gnu.org> <83k4aasnm9.fsf@gnu.org> <838vqmx9tj.fsf@gnu.org> <83ei0cimdl.fsf@gnu.org> <831uwchrvw.fsf@gnu.org> <83wre3gp2h.fsf@gnu.org> <83r54ahhpr.fsf@gnu.org> <83d3fuggu5.fsf@gnu.org> <83wre0fx1z.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1314413631 15491 80.91.229.12 (27 Aug 2011 02:53:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 27 Aug 2011 02:53:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 27 04:53:47 2011 Return-path: Envelope-to: ged-emacs-devel@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 1Qx91n-00039t-3O for ged-emacs-devel@m.gmane.org; Sat, 27 Aug 2011 04:53:47 +0200 Original-Received: from localhost ([::1]:58707 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qx91m-0001oJ-EA for ged-emacs-devel@m.gmane.org; Fri, 26 Aug 2011 22:53:46 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:39953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qx91i-0001nU-Tc for emacs-devel@gnu.org; Fri, 26 Aug 2011 22:53:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qx91h-0007Bu-Fa for emacs-devel@gnu.org; Fri, 26 Aug 2011 22:53:42 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:32827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qx91h-0007Bg-8O; Fri, 26 Aug 2011 22:53:41 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id p7R2rbrn022372; Fri, 26 Aug 2011 22:53:39 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 11CAD660CF; Fri, 26 Aug 2011 22:53:36 -0400 (EDT) In-Reply-To: <83wre0fx1z.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Aug 2011 10:31:52 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3961=0 X-NAI-Spam-Version: 2.2.0.9286 : core <3961> : streams <675498> : uri <944408> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:143599 Archived-At: > I guess what I'm saying is that the API will almost certainly change > as we gain experience. So I'm unsure how elaborate we should make it > at this point, because any mistake will mean more changes in the > future when the API changes. Right. Better not solve this problem yet. > we insert LRM/RLM between NAME and . The difficulty is that you > need to know in advance the paragraph direction where the string will > be inserted. This means the embedding should happen very close to Hmm... so UAX#9 does not give us the tools we need, here. > There's a similar issue with file names: /abcd/ABCD/XYZ will be > displayed as /abcd/ZYX/DCBA. IIUC in an English paragraph this should be displayed as /abcd/DCBA/ZYX but in a Hebrew paragraph it should be displayed as ZYX/DCBA/abcd/, right? > Btw, using LRM/RLM is always preferred when possible, because it's > stateless, as opposed to an embedding. UAX#9 says that much. Also, Yes, that makes a lot of sense (just think of using substring to select part of the embedding, dropping the initial or final marker). So embeddings should not be used too much, and/or should only be used dynamically (jit-lock-style) and implicitly (e.g. not copied by kill-region). > So a related question is: should we prefer the marks where possible, > or should we standardize on embeddings? I'm not sure we are equipped > with enough experience to decide at this time. Agreed. > However, an important practical question is: which alternative to use > to fix read_minibuf, for example? I don't think it matters too much; just use whatever works best. Stefan