From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: change in X character input processing Date: Fri, 01 Nov 2002 10:54:01 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200211011554.gA1Fs1I03134@rum.cs.yale.edu> References: <200210311520.g9VFKQH28182@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1036166049 5473 80.91.224.249 (1 Nov 2002 15:54:09 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 1 Nov 2002 15:54:09 +0000 (UTC) Cc: "Stefan Monnier" , emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 187e7b-0001Q6-00 for ; Fri, 01 Nov 2002 16:54:07 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 187eDj-0002sF-00 for ; Fri, 01 Nov 2002 17:00:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 187e8V-0007pm-00; Fri, 01 Nov 2002 10:55:03 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 187e7j-0007gI-00 for emacs-devel@gnu.org; Fri, 01 Nov 2002 10:54:15 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 187e7h-0007fo-00 for emacs-devel@gnu.org; Fri, 01 Nov 2002 10:54:14 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 187e7g-0007fe-00 for emacs-devel@gnu.org; Fri, 01 Nov 2002 10:54:12 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id gA1Fs1I03134; Fri, 1 Nov 2002 10:54:01 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Dave Love Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9040 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9040 > "Stefan Monnier" writes: > > > IIUC this doesn't prevent the usual Xlib decoding of keysym, but > > only uses an auxiliary table x-keysym-table to map keysyms > > to characters in case where Xlib failed to decode the keysym > > (typically because it can't be represented in the user's > > locale). > > The idea is to translate known character keysyms directly to the > appropriate characters. This should be entirely straightforward, > unlike the situation where you have to try to match X's and Emacs's > idea of the encoding, potentially with input from a different locale > from the one in which Emacs is running. Yes, I understand that part. The question is: when is your code used; in which case(s) does it change the previous behavior. > > I.e. it is similar in behavior to my earlier patch which tried > > Xutf8LookupString if XmbLookupString failed (except that your patch > > doesn't rely on the deprecated Xutf8LookupString function or any > > other extra support in Xlib for that matter). > I don't know about that, but presumably not. Actually, having looked at the code some more, I'd say "yes, it does the same thing, except it does it itself rather than with Xlib's help" > Avoiding Xlib > restrictions is part of the idea, e.g. you can use a euro key without > Latin-9 support from Xlib. Yes, but the behavior is the same: if XmbLookupString manages to decode the keysym into a char, then the old code is used. If it doesn't, my code tried Xutf8StringLookup whereas your code uses x-keysym-table. When the two table are similar, you get pretty much the same behavior. Not relying on Xlib is of course an advantage right now since unicode support in Xlib can't be relied upon. Stefan