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: Wed, 06 Nov 2002 14:19:39 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200211061919.gA6JJd203951@rum.cs.yale.edu> References: <200210311520.g9VFKQH28182@rum.cs.yale.edu> <200211011953.gA1Jred05539@rum.cs.yale.edu> <200211030306.gA336Q310809@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 1036611542 31109 80.91.224.249 (6 Nov 2002 19:39:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 6 Nov 2002 19:39:02 +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 189W0t-00084x-00 for ; Wed, 06 Nov 2002 20:38:55 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 189W9W-0001rj-00 for ; Wed, 06 Nov 2002 20:47:50 +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 189VxX-0004Ix-00; Wed, 06 Nov 2002 14:35:27 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 189Viu-0000We-00 for emacs-devel@gnu.org; Wed, 06 Nov 2002 14:20:20 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 189ViM-0000KZ-00 for emacs-devel@gnu.org; Wed, 06 Nov 2002 14:20:17 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 189ViL-0000Jb-00 for emacs-devel@gnu.org; Wed, 06 Nov 2002 14:19:46 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id gA6JJd203951; Wed, 6 Nov 2002 14:19:39 -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:9198 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9198 > > 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? > > No. Previously nothing outside Quail tried to conform to the file > coding system of the current buffer. I meant to compare old xterm.c code with new input translation table setup vs new xterm.c code with new input translation table setup > > 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. > > As I understand it, there currently isn't a proper definition of the > translation of many keysyms, and thus no guarantee of consistency > across platforms. For instance, EuroSign, which my Sun keyboard > generates under XFree, isn't defined on Solaris 8. > > > Among other things, that means that it is kept uptodate > > and populated without any work on our part. > > But there isn't a single Xlib, especially one that can be relied to be > at all `up-to-date' on random systems, and the input may be coming > from a different system. I don't think it's any more reasonable to > depend on Xlib than on iconv routines on the system, say. There is one significant way in which it is more reasonable: 99% of the programs rely on it. So if your Xlib doesn't understand EuroSign, then none of your programs will understand it, so I don't see why Emacs should go through extra trouble: the problem should obviously be fixed in Xlib anyway. > > 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. > I don't want it backwards-compatible, because that doesn't DTRT with > high probability. Could you give some example where the old code does turn the event into a char but doesn't do it right ? That's obviously the only relevant case since if it fails to turn it into a char we all agree that we should then use x-keysym-table. > Also it doesn't seem sensible to decode every > character, though I don't know whether that's a significant > inefficiency. Indeed, the efficiency aspect is irrelevant. > Afraid I haven't got the keyboard translation sorted out yet, partly > because I realized it should use `keyboard-translate-table'. I think as long as this is not fixed, your new code's behavior is wrong. Preferring the decode rather than the x-keysym-table would not suffer from this problem. That's one of the ways in which backward compatibility is beneficial. Stefan