[mule] xemacs doesn't recognize some symbols

[Aidan Kehoe]

 Ar an seacht? l? is fiche de m? Deireadh F?mhair, scr?obh 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. ???????????).

Those should disappear if you use more recent sources, dating since after
this patch was committed:

http://mid.gmane.org/17522.5887.730211.185772@parhasard.net

 > 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

Yup, because you don?t have any fonts on your system to handle that encoding
(the XLFD needs to end with cns11643-1). I have most of a solution to that
problem on my hard disk--if the font isn?t available, it tries the Unicode
encoding instead--but it needs some more testing and debugging.

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

Can I enable the key layout you?re using with

  setxkbmap ua 

? If so, I will try to investigate further this evening. I am seeing
unexpected behaviour with GHE WITH UPTURN on this Windows machine?s Cygwin
install, but it?s different to what you?re seeing. 

-- 
Santa Maradona, priez pour moi!