Re: change in X character input processing

[Dave Love <d.love@dl.ac.uk>]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> 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.

> 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.

> 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.  Also it doesn't seem sensible to decode every
character, though I don't know whether that's a significant
inefficiency.

Afraid I haven't got the keyboard translation sorted out yet, partly
because I realized it should use `keyboard-translate-table'.