[mule] xemacs doesn't recognize some symbols

[Andriy Gapon]

Guys, thank you for your enlightening explanation!

I decided to give a try to xemacs-21.5.27.
Overall I have more success, but I've encountered somewhat different
problems.

First and the least important:
(key-mapping/info) Undefined Unicode key mappings.
Your keyboard has, among many others, the following keysyms defined:

    U20B4 U0301
...
The first symbol is HRYVNIA SIGN (?), a symbol for Ukrainian currency,
this is a very very recent addition to Unicode so I don't complain much.
The second one is COMBINING ACUTE ACCENT that I use as a stress sign for
cyrillic (e.g. ???????????).

Then, there is a different problem with EM DASH and EN DASH now: they
seem to get entered, but a tilde is displayed instead of them and the
following warning is produced:
(font/notice) Unable to instantiate font for charset chinese-cns11643-1,
face default
I use Terminus monospace font with unicode encoding and it definitely
has these symbols. This is definitely not an input problem because
copy/paste has the same result.

Then, I still can not enter CYRILLIC CAPITAL/SMALL LETTER GHE WITH
UPTURN, but there is no special warning now, maybe because of the following.

Unusual thing with input is that when, e.g., I press AltGr+? to get "?",
I instead get "u" (ascii latin small letter). By "AltGr" I mean
ISO_Level3_Shift in X. Analogous thing happens for any other AltGr
combination that results in a "problematic" symbol ? AltGr is treated as
if it was "Mode_switch".
Now that I wrote it, I realize that most probably this is not a problem
with XEmacs but rather a feature that is triggered by my hackery of XKB:
$ xmodmap -pm | fgrep ISO_Level3_Shift
mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x75),
ISO_Level3_Shift (0x7c)
So, maybe XEmacs falls back to Mode_switch interpretation of Mod5 if it
thinks that ISO_Level3_Shift is no good ? And by "no good" I mean that a
key has 3rd/4th level and symbols on that level are not NULL(0), but
they are not valid input for XEmacs.
I must say that I haven't seen such a behavior from any other program.
And I don't really have any key bound to Mode_switch (93 is a fake key
code, it is never produced by a xfree86 keyboard driver).


-- 
Andriy Gapon