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: bidi and shaping problems in describe-input-method Date: Mon, 12 Mar 2012 19:42:41 +0200 Message-ID: <8362e9yaum.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1331574209 20744 80.91.229.3 (12 Mar 2012 17:43:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 12 Mar 2012 17:43:29 +0000 (UTC) Cc: list-general@mohsen.1.banan.byname.net, emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 12 18:43:25 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S79HC-00085g-8u for ged-emacs-devel@m.gmane.org; Mon, 12 Mar 2012 18:43:18 +0100 Original-Received: from localhost ([::1]:52496 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S79HB-0000mM-NU for ged-emacs-devel@m.gmane.org; Mon, 12 Mar 2012 13:43:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S79H3-0000lf-5P for emacs-devel@gnu.org; Mon, 12 Mar 2012 13:43:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S79GU-0000wm-Ty for emacs-devel@gnu.org; Mon, 12 Mar 2012 13:43:08 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:43332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S79GU-0000wb-LA for emacs-devel@gnu.org; Mon, 12 Mar 2012 13:42:34 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M0S00N0096T3S00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 12 Mar 2012 19:42:33 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.179.236]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M0S00MHG96U7HH0@a-mtaout22.012.net.il>; Mon, 12 Mar 2012 19:42:31 +0200 (IST) 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.172 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:148978 Archived-At: > From: Kenichi Handa > Cc: list-general@mohsen.1.banan.byname.net, emacs-devel@gnu.org > Date: Mon, 12 Mar 2012 16:47:11 +0900 > > In article <8362eczr73.fsf@gnu.org>, Eli Zaretskii writes: > > > Yes. But surrounding each `lower' and `upper' key labels in the > > layout with LRE..PDF inserts even more bidirectional control > > characters than just inserting LRM. By contrast, using LRO..PDF > > around the whole row of keys inserts just 2 such characters, so if it > > were not for the need to reorder the individual key labels, LRO..PDF > > would be a better alternative. I mentioned it because it does exactly > > what you originally asked for: it effectively disables > > bidi-display-reordering inside the embedded text, while still leaving > > the rest of the buffer reordered as usual. > > I mixed up with LRE and LRO, sorry. Anyway, if LRO..PDF > works, it is surely better than many LRMs. I've just > installed a proper change including the magic of > compose-string. Please try the latest code. It works fine for me, thanks. However, using LRO..PDF means that no label on a key can use a string that needs to be reordered. That's because the LRO overrides the bidirectional properties of all the following characters to be strong L. If we can live with this limitation, I agree that this is better. But I think you said earlier that such a restriction is more than we can bear.