Re: change in X character input processing

[Stefan Monnier]

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

No, indeed it doesn't invalidate the point because the point was not
about multilingualism but about what happens when you generate a particular
keysym_press event perfectly understood by Xlib in the current locale.

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

I'm not talking about the case where the locale cannot represent the
character.  As I've said repeatedly, in that case clearly the Emacs-21.3
code is not sufficient and something like x-keysym-table is necessary.
I don't object at all to that part of your code.

What I object to is that your code bypasses Xlib even in the cases
where Xlib used to do things just fine.  It is unnecessary and subtly
changes the behavior of the code, leading to potential unexpected
behaviors.  My point is that we don't need to make such behavioral
changes.

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

I think you know by now that "doesn't DTRT" is not a useful description
of a problem.  AFAIK, it worked fine: it inserted a latin-1 £ and
your x-keysym-table code doesn't make any change here.

The translation-table-for-input change does make a difference, but it
is unrelated to the topic I'm discussing. (except for the fact that it
hides most of the incompatible changes introduced by your x-keysym-table
change that I'm objecting to).

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

I don't see in what way this is relevant.

> > Indeed, the efficiency aspect is irrelevant.
> What are the figures?

It's done once per keypress.  If decoding a couple of bytes takes
a significant part of the keypress-handling time, then we're in
real trouble.

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

I don't think so, but if the code only used x-keysym-table when Xlib
failed it would work just as well, so I really don't see why we should
introduce this risk of incompatible change.
What is the big deal with reverting to "try Xlib first and if that
fails, try x-keysym-table" ?  It would turn your x-keysym-table feature
into an "obviously safe" thing, whereas right now, it's only "probably safe
provided translation-table-for-input is setup corrctly".


        Stefan


PS: the current code still behaves differently in that the events corresponding
    to a keypress have not gone through translation-table-for-input yet, so
    in a latin-9 locale, those events used to be latin-9 chars whereas
    they are now mostly-latin-1-chars.  This shouldn't make too much of
    a difference in practice (except when people create bindings for
    non-ASCII keys maybe, or a few pieces of code that do something
    similar to self-insert-command).