From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
Cc: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>,
emacs-devel@gnu.org
Subject: Re: change in X character input processing
Date: Wed, 06 Nov 2002 14:19:39 -0500 [thread overview]
Message-ID: <200211061919.gA6JJd203951@rum.cs.yale.edu> (raw)
In-Reply-To: rzq8z06jz9v.fsf@albion.dl.ac.uk
> > 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
next prev parent reply other threads:[~2002-11-06 19:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-31 10:55 change in X character input processing Dave Love
2002-10-31 15:20 ` Stefan Monnier
2002-11-01 13:54 ` Dave Love
2002-11-01 15:54 ` Stefan Monnier
2002-11-01 19:53 ` Stefan Monnier
2002-11-02 13:51 ` Dave Love
2002-11-03 3:06 ` Stefan Monnier
2002-11-06 19:04 ` Dave Love
2002-11-06 19:19 ` Stefan Monnier [this message]
2002-11-07 10:34 ` Kim F. Storm
2002-11-11 20:08 ` Dave Love
2002-11-11 19:59 ` Dave Love
2002-11-11 20:35 ` Stefan Monnier
2002-10-31 15:31 ` Stefan Monnier
2002-11-01 13:58 ` Dave Love
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200211061919.gA6JJd203951@rum.cs.yale.edu \
--to=monnier+gnu/emacs@rum.cs.yale.edu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.