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!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta