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: Fri, 09 Mar 2012 18:12:46 +0200 Message-ID: <83pqclzrb5.fsf@gnu.org> References: <87zkbpvpl7.fsf@m17n.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1331309640 15762 80.91.229.3 (9 Mar 2012 16:14:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 9 Mar 2012 16:14:00 +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 Fri Mar 09 17:13:57 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 1S62Rz-0005Yd-Gd for ged-emacs-devel@m.gmane.org; Fri, 09 Mar 2012 17:13:51 +0100 Original-Received: from localhost ([::1]:49473 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S62Ry-0005YT-PX for ged-emacs-devel@m.gmane.org; Fri, 09 Mar 2012 11:13:50 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S62Ro-0005Gj-J8 for emacs-devel@gnu.org; Fri, 09 Mar 2012 11:13:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S62Rf-0004aY-2u for emacs-devel@gnu.org; Fri, 09 Mar 2012 11:13:40 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:50877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S62Re-0004Zt-R6 for emacs-devel@gnu.org; Fri, 09 Mar 2012 11:13:31 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M0M00600KZNHS00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 09 Mar 2012 18:12:42 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.229.138.42]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M0M006XFL1326B0@a-mtaout22.012.net.il>; Fri, 09 Mar 2012 18:12:40 +0200 (IST) In-reply-to: <87zkbpvpl7.fsf@m17n.org> 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:148953 Archived-At: > From: Kenichi Handa > Cc: list-general@mohsen.1.banan.byname.net, emacs-devel@gnu.org > Date: Fri, 09 Mar 2012 23:03:32 +0900 > > In article <83d38m19dk.fsf@gnu.org>, Eli Zaretskii writes: > > > > If possible, I'd like to avoid inserting LRM unconditionally. > > > Why? They are invisible, so they are not displayed at all. > > In general, it's smarter to use LRM only where necessary. Testing whether they are necessary is a problem in itself. You can easily avoid inserting the marks for strong L2R characters, but they are the minority. Most of the characters are not in that category. And of course keyboard layouts include such characters. > > > (defun quail-help-require-LRM (char) > > > (or (eq (get-char-code-property char 'bidi-class) 'L) > > > ...)) > > > It's possible, but why bother? And with this function you will insert > > the LRM for many characters that don't need that, like punctuation, > > numbers, etc. > > ??? I want a function that returns t only for a character > that require preceding LRM in the keyboard layout. Yes, I understand that. But the test you are suggesting, i.e. avoid the LRM only for characters whose bidi-class is L, will not catch numbers, punctuation, and other non-L characters. > > Also, `lower' and `upper' could be strings, in which case you need a > > more complex test. > > We can give (if (string lower) (aref lower 0) lower) to that > function. But that doesn't DTRT. Here's an example where it will fail: ".A". AFAIK, the only reliable way of telling whether a given string will be reordered is to actually reorder it, and then compare with the logical-order original. That's a nuisance, and also the results may well depend on the characters before and after the string in the buffer, so you need to know the context in advance, which you normally don't. I tried also a different solution: enclose each row of the keyboard layout in an L2R override embedding, LRO..PDF. This inserts only 2 control characters per row, and doesn't insert them inside the keyboard cells, so it is cleaner, I think. But using this means that no key description in the layout can be a string that requires reordering individually. (By contrast, inserting an LRM between the lower and the upper key still allows each description to be reordered.) Can we live with such a restriction? I don't know enough about Quail to tell.