Re: change in X character input processing

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

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

> IIUC this doesn't prevent the usual Xlib decoding of keysym, but
> only uses an auxiliary table x-keysym-table to map keysyms
> to characters in case where Xlib failed to decode the keysym
> (typically because it can't be represented in the user's
> locale).

The idea is to translate known character keysyms directly to the
appropriate characters.  This should be entirely straightforward,
unlike the situation where you have to try to match X's and Emacs's
idea of the encoding, potentially with input from a different locale
from the one in which Emacs is running.

Note that I don't understand XIM -- is there a good introduction? --
and I don't know whether Emacs really DTRT with XIM.  I don't think
what I've done affects it, anyhow, and if it causes problems it can be
fixed or reverted.

> I.e. it is similar in behavior to my earlier patch which tried
> Xutf8LookupString if XmbLookupString failed (except that your patch
> doesn't rely on the deprecated Xutf8LookupString function or any
> other extra support in Xlib for that matter).

I don't know about that, but presumably not.  Avoiding Xlib
restrictions is part of the idea, e.g. you can use a euro key without
Latin-9 support from Xlib.