Re: change in X character input processing

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

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

Yes, I understand that part.  The question is: when is your code used;
in which case(s) does it change the previous behavior.

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

Actually, having looked at the code some more, I'd say "yes, it does the
same thing, except it does it itself rather than with Xlib's help"

> Avoiding Xlib
> restrictions is part of the idea, e.g. you can use a euro key without
> Latin-9 support from Xlib.

Yes, but the behavior is the same: if XmbLookupString manages to decode
the keysym into a char, then the old code is used.  If it doesn't,
my code tried Xutf8StringLookup whereas your code uses x-keysym-table.
When the two table are similar, you get pretty much the same behavior.
Not relying on Xlib is of course an advantage right now since unicode
support in Xlib can't be relied upon.


	Stefan