Re: change in X character input processing

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

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

> The new code you installed works very differently from the one you had before.
> Now your x-keysym-table overrides the usual XmbLookupString+decode process
> This means that when you do
> 
> 	LANG=fr_FR@euro emacs -q --no-site-file
> 
> with your code an eacute will insert a latin-1 eacute whereas with
> the previous code it inserted a latin-9 eacute.

Sorry, I forgot the input translation table never got used properly.
It should affect self-inserting characters, but I couldn't do that
originally (in Lisp).  The situation above is the same as for Quail
methods, and I think it's strictly correct insofar as X uses iso2022
and defines the keysym to be Latin-1, but obviously it's not what you
want.

I'll sort out the translation table, then you'll get a high
probability of translating the input character appropriately for the
buffer context, regardless of the locale.  I probably can't test that
under X before Monday.

If the current code is causing anyone problems, setting
`x-keysym-table' to an empty hash table should give the same behaviour
as before.

[The input translation may be useful for more charsets than currently
supported.  See ucs-tables.el if anyone wants to add more tables that
are useful and not too big.  If they are big (2-dimensional charsets),
they should probably just be added to the translation tables in
appropriate language environments.]