Re: change in X character input processing

[Dave Love]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

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

In that case, yes.

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

99% of programs probably aren't multilingual.  I don't know of another
one that is, like Emacs, or guidance on writing one.  I don't think
that invalidates the point anyhow.

> So if your Xlib doesn't understand EuroSign,
> then none of your programs will understand it,

Whether or not they understand it, they probably aren't going to do
anything useful with it in a locale whose charset doesn't represent
it.  That isn't specific to euro.

> so I don't see why Emacs should go through extra trouble:

I've gone to the trouble anyway.

> the problem should obviously be fixed in Xlib anyway.

I think that's unrealistic.  There are assorted things that doubtless
should be done differently outside Emacs for which Emacs compensates.

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

I'm not sure you're talking about the same thing, but what I meant
was: typing £ from a Latin-1 keyboard into a Latin-9 buffer didn't
DTRT previously.

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

I know how to DTRT at least as well as old Xlibs, the result will be
consistent, and it can be customized.  There may or may not be Xlibs
which translate certain keysyms wrongly in given locales.  I don't
have examples, but I'd be surprised if they didn't exist.  You're not
at their mercy.  If you think that character conversions are trivial
and well-defined, consider alternativnyj as an 8-bit example, and
jisx0208 as a multibyte one.  Note also that there aren't even
unicodes for some of the defined keysyms.

> Indeed, the efficiency aspect is irrelevant.

What are the figures?

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

I said that should be used.  It is now (reverting to the original
translation table usage following handa's comment).

Are there now cases where it fails to DTRT according to what a user is
likely to expect and where it reasonably could?