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: Mon, 11 Nov 2002 15:35:00 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200211112035.gABKZ0t17610@rum.cs.yale.edu> References: <200210311520.g9VFKQH28182@rum.cs.yale.edu> <200211011953.gA1Jred05539@rum.cs.yale.edu> <200211030306.gA336Q310809@rum.cs.yale.edu> <200211061919.gA6JJd203951@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1037201075 20326 80.91.224.249 (13 Nov 2002 15:24:35 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 13 Nov 2002 15:24:35 +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 18BzCb-00047g-00 for ; Wed, 13 Nov 2002 16:13:13 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18BzOY-00066k-01 for ; Wed, 13 Nov 2002 16:25:34 +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 18BLXq-00046d-00; Mon, 11 Nov 2002 15:52:30 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18BLHB-0002Hi-00 for emacs-devel@gnu.org; Mon, 11 Nov 2002 15:35:17 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18BLH5-0002Gb-00 for emacs-devel@gnu.org; Mon, 11 Nov 2002 15:35:14 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18BLH5-0002G9-00 for emacs-devel@gnu.org; Mon, 11 Nov 2002 15:35:11 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id gABKZ0t17610; Mon, 11 Nov 2002 15:35:00 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Dave Love X-MIME-Autoconverted: from 8bit to quoted-printable by rum.cs.yale.edu id gABKZ0t17610 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:9346 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9346 > > > 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. > >=20 > > There is one significant way in which it is more reasonable: 99% of > > the programs rely on it. >=20 > 99% of programs probably aren't multilingual. I don't know of another > one that is, like Emacs, or guidance on writing one. I don't think > that invalidates the point anyhow. No, indeed it doesn't invalidate the point because the point was not about multilingualism but about what happens when you generate a particul= ar keysym_press event perfectly understood by Xlib in the current locale. > > So if your Xlib doesn't understand EuroSign, > > then none of your programs will understand it, >=20 > Whether or not they understand it, they probably aren't going to do > anything useful with it in a locale whose charset doesn't represent > it. That isn't specific to euro. I'm not talking about the case where the locale cannot represent the character. As I've said repeatedly, in that case clearly the Emacs-21.3 code is not sufficient and something like x-keysym-table is necessary. I don't object at all to that part of your code. What I object to is that your code bypasses Xlib even in the cases where Xlib used to do things just fine. It is unnecessary and subtly changes the behavior of the code, leading to potential unexpected behaviors. My point is that we don't need to make such behavioral changes. > > > I don't want it backwards-compatible, because that doesn't DTRT wit= h > > > high probability. > >=20 > > Could you give some example where the old code does turn the event in= to > > a char but doesn't do it right ? >=20 > I'm not sure you're talking about the same thing, but what I meant > was: typing =A3 from a Latin-1 keyboard into a Latin-9 buffer didn't > DTRT previously. I think you know by now that "doesn't DTRT" is not a useful description of a problem. AFAIK, it worked fine: it inserted a latin-1 =A3 and your x-keysym-table code doesn't make any change here. The translation-table-for-input change does make a difference, but it is unrelated to the topic I'm discussing. (except for the fact that it hides most of the incompatible changes introduced by your x-keysym-table change that I'm objecting to). > and well-defined, consider alternativnyj as an 8-bit example, and > jisx0208 as a multibyte one. Note also that there aren't even > unicodes for some of the defined keysyms. I don't see in what way this is relevant. > > Indeed, the efficiency aspect is irrelevant. > What are the figures? It's done once per keypress. If decoding a couple of bytes takes a significant part of the keypress-handling time, then we're in real trouble. > > > Afraid I haven't got the keyboard translation sorted out yet, partl= y > > > because I realized it should use `keyboard-translate-table'. > >=20 > > I think as long as this is not fixed, your new code's behavior > > is wrong. >=20 > I said that should be used. It is now (reverting to the original > translation table usage following handa's comment). >=20 > Are there now cases where it fails to DTRT according to what a user is > likely to expect and where it reasonably could? I don't think so, but if the code only used x-keysym-table when Xlib failed it would work just as well, so I really don't see why we should introduce this risk of incompatible change. What is the big deal with reverting to "try Xlib first and if that fails, try x-keysym-table" ? It would turn your x-keysym-table feature into an "obviously safe" thing, whereas right now, it's only "probably sa= fe provided translation-table-for-input is setup corrctly". Stefan PS: the current code still behaves differently in that the events corresp= onding to a keypress have not gone through translation-table-for-input yet, = so in a latin-9 locale, those events used to be latin-9 chars whereas they are now mostly-latin-1-chars. This shouldn't make too much of a difference in practice (except when people create bindings for non-ASCII keys maybe, or a few pieces of code that do something similar to self-insert-command).