Re: change in X character input processing

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

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

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

That's a good point.  I think my main question is: which mapping table
should be preferred.  The options we have already seen are:
- originally, only one table was used: the Xlib table for the current locale.
- my utf8 patch temporarily changed it to: first try the Xlib table for
  the current locale and if that fails, try the Xlib table for a utf-8 locale.
- your first patch said: first try the Xlib table for the current locale
  and if that fails, try the x-keysym-table.
- the current code does: try x-keysym-table and if that fails, use
  the Xlib table for the current locale.

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.  Among other
things, that means that it is kept uptodate and populated without
any work on our part.  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.


	Stefan