Re: change in X character input processing

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

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

I meant to compare

	old xterm.c code with new input translation table setup
vs
	new xterm.c code with new input translation table setup

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

There is one significant way in which it is more reasonable: 99% of
the programs rely on it.  So if your Xlib doesn't understand EuroSign,
then none of your programs will understand it, so I don't see why
Emacs should go through extra trouble: the problem should obviously
be fixed in Xlib anyway.

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

Could you give some example where the old code does turn the event into
a char but doesn't do it right ?
That's obviously the only relevant case since if it fails to turn it into
a char we all agree that we should then use x-keysym-table.

> Also it doesn't seem sensible to decode every
> character, though I don't know whether that's a significant
> inefficiency.

Indeed, the efficiency aspect is irrelevant.

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

I think as long as this is not fixed, your new code's behavior
is wrong.  Preferring the decode rather than the x-keysym-table
would not suffer from this problem.  That's one of the ways in which
backward compatibility is beneficial.


	Stefan