From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: bidi and shaping problems in describe-input-method Date: Fri, 09 Mar 2012 00:30:25 +0900 Message-ID: <87fwdjw1ny.fsf@m17n.org> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1331220692 3563 80.91.229.3 (8 Mar 2012 15:31:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 8 Mar 2012 15:31:32 +0000 (UTC) Cc: eliz@gnu.org, emacs-devel@gnu.org To: Mohsen BANAN Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 08 16:31:30 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 1S5fJN-0003db-Gq for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2012 16:31:25 +0100 Original-Received: from localhost ([::1]:52189 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5fJM-0005tN-Sa for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2012 10:31:24 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5fJE-0005t1-SI for emacs-devel@gnu.org; Thu, 08 Mar 2012 10:31:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S5fJA-0000FP-2u for emacs-devel@gnu.org; Thu, 08 Mar 2012 10:31:16 -0500 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:40457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5fIy-0000D2-Ha; Thu, 08 Mar 2012 10:31:00 -0500 Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id q28FUsNb020363; Fri, 9 Mar 2012 00:30:54 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id q28FUs2C009573; Fri, 9 Mar 2012 00:30:54 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp3.aist.go.jp with ESMTP id q28FUrUP026120; Fri, 9 Mar 2012 00:30:53 +0900 (JST) env-from (handa@m17n.org) In-Reply-To: (message from Mohsen BANAN on Wed, 07 Mar 2012 13:32:07 -0800) X-detected-operating-system: by eggs.gnu.org: Solaris 9 X-Received-From: 150.29.246.133 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:148933 Archived-At: In article , Mohsen BANAN writes: Mohsen> The second problem is shaping related: Mohsen>=20 Mohsen> Inside of a cell on the keyboard layout, when Mohsen> there are two characters that can be joined, they Mohsen> are joined -- be default. They should not be. Eli> How can one know when they should be joined and when not? > I think the simple answer is: always isolated -- never joined. > For Persian and Arabic I am sure that they should > never be joined -- always isolated.=20 Sure. > For other shaped languages, it is hard to imagine > an input method designer would ever want them joined. I agree. > For non-shaped languages (e.g., latin keyboards) > the insertion of an zero width non-joiner between > lower and upper case is harmless and invisible. > So, the simplest fix (and perhaps > the-right-thing-to-do) is to ALWAYS insert a > (ucs-insert 8204)=E2=80=8C -- zero width non-joiner -- > between the two characters in each and every > keyboard cell. If we insert something unconditionally, I think inserting (propertize " " 'invisible t) is safer. It should work on tty terminal too. By the way, for this bug: Mohsen> In the case of 'arabic note how the entire Mohsen> keyboard is flipped to the right. just setting bidi-paragraph-direction to 'left-to-right is not enough, because keyboard cells in a row are still re-ordered. For this, the easiest fix is to set bidi-display-reordering to nil. But, then we can't use actual Arabic and Hebrew words in the docstrings of those input methods. What we want is to display bidi reordering only for the keyboard layout part. Eli, don't you have any good idea? --- Kenichi Handa handa@m17n.org