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: Sat, 02 Nov 2002 22:06:26 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200211030306.gA336Q310809@rum.cs.yale.edu> References: <200210311520.g9VFKQH28182@rum.cs.yale.edu> <200211011953.gA1Jred05539@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 1036293563 12440 80.91.224.249 (3 Nov 2002 03:19:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 3 Nov 2002 03:19:23 +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 188BIH-0003EV-00 for ; Sun, 03 Nov 2002 04:19:21 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 188BP6-0007fn-00 for ; Sun, 03 Nov 2002 04:26:25 +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 188BGQ-0000uV-00; Sat, 02 Nov 2002 22:17:26 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 188B5s-0004qC-00 for emacs-devel@gnu.org; Sat, 02 Nov 2002 22:06:32 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 188B5o-0004oJ-00 for emacs-devel@gnu.org; Sat, 02 Nov 2002 22:06:31 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 188B5o-0004nL-00 for emacs-devel@gnu.org; Sat, 02 Nov 2002 22:06:28 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id gA336Q310809; Sat, 2 Nov 2002 22:06:26 -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:9080 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9080 > > The new code you installed works very differently from the one you had before. > > Now your x-keysym-table overrides the usual XmbLookupString+decode process > > This means that when you do > > > > LANG=fr_FR@euro emacs -q --no-site-file > > > > with your code an eacute will insert a latin-1 eacute whereas with > > the previous code it inserted a latin-9 eacute. > > Sorry, I forgot the input translation table never got used properly. > It should affect self-inserting characters, but I couldn't do that > originally (in Lisp). The situation above is the same as for Quail > methods, and I think it's strictly correct insofar as X uses iso2022 > and defines the keysym to be Latin-1, but obviously it's not what you > want. > > I'll sort out the translation table, then you'll get a high > probability of translating the input character appropriately for the > buffer context, regardless of the locale. I probably can't test that > under X before Monday. If I understand correctly, once the input translation table is setup, then the difference I pointed out above between the old code and the new code would mostly vanish: both would return a char in the charset most closely related to the buffer's coding system. Right? > If the current code is causing anyone problems, setting > `x-keysym-table' to an empty hash table should give the same behaviour > as before. That's a good point. I think my main question is: which mapping table should be preferred. The options we have already seen are: - originally, only one table was used: the Xlib table for the current locale. - my utf8 patch temporarily changed it to: first try the Xlib table for the current locale and if that fails, try the Xlib table for a utf-8 locale. - your first patch said: first try the Xlib table for the current locale and if that fails, try the x-keysym-table. - the current code does: try x-keysym-table and if that fails, use the Xlib table for the current locale. The use of x-keysym-table has the advantage of flexibility, since we don't depend on the Xlib at all. But I tend to prefer the Xlib table because I think of it as canonical since every application uses it. Among other things, that means that it is kept uptodate and populated without any work on our part. For that reason I'd prefer using the code that you first installed, which prefers the Xlib table to the x-keysym-table. Of course I also prefer it because it offers better backward compatibility. Stefan