From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105429: New function `string-mark-left-to-right' for handling LRMs. Date: Thu, 11 Aug 2011 06:02:39 +0300 Message-ID: <83ei0sy7jk.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1313031778 27644 80.91.229.12 (11 Aug 2011 03:02:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 11 Aug 2011 03:02:58 +0000 (UTC) Cc: cyd@stupidchicken.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 11 05:02:54 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 1QrLXp-0001d9-AJ for ged-emacs-devel@m.gmane.org; Thu, 11 Aug 2011 05:02:53 +0200 Original-Received: from localhost ([::1]:59985 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrLXo-0002S2-GH for ged-emacs-devel@m.gmane.org; Wed, 10 Aug 2011 23:02:52 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38665) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrLXj-0002Re-5C for emacs-devel@gnu.org; Wed, 10 Aug 2011 23:02:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrLXb-00089i-Dj for emacs-devel@gnu.org; Wed, 10 Aug 2011 23:02:46 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:45838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrLXb-00089e-69 for emacs-devel@gnu.org; Wed, 10 Aug 2011 23:02:39 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LPQ00G00TNNVV00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Thu, 11 Aug 2011 06:02:38 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.94.185]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LPQ00G7ITSCDNK0@a-mtaout20.012.net.il>; Thu, 11 Aug 2011 06:02:37 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 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:143136 Archived-At: > From: Stefan Monnier > Date: Wed, 10 Aug 2011 22:14:28 -0400 > Cc: emacs-devel@gnu.org > > > +** New function `string-mark-left-to-right' appends a Unicode LRM > > +(left-to-right mark) character to a string if it terminates in > > +right-to-left script. This algorithm (which the code implements) is wrong: the unwanted reordering can happen even if the string does not end in a strong R character. It could end in a series of weak characters, if the strong character preceding that is R, for example. The precise definition of the necessary conditions is complicated. That is why I suggested to test _all_ the characters for being strong R. Why wasn't that implemented? It might catch more strings that need this, but at least it won't miss any. If we really want only a 100% accurate solution, I will need to code something non-trivial. Let me know. > This is useful when the buffer has overall > > +left-to-right paragraph direction and you need to insert a string > > +whose contents (and directionality) are not known in advance. > > This is too low-level a description I think. It's understandable by > people who understand what LRM does I think even people who know about that won't realize the purpose. > Maybe something along the lines of > > "Add whatever is necessary for STRING to make sure its content is not > reordered with surrounding text" This is also incorrect or at least inaccurate. The problem is with reordering the text following the offending string, not surrounding it, nor with reordering the string content itself.