[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: change in X character input processing
From: |
Stefan Monnier |
Subject: |
Re: change in X character input processing |
Date: |
Wed, 06 Nov 2002 14:19:39 -0500 |
> > 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