[mule] xemacs doesn't recognize some symbols

[Andriy Gapon]

on 27/10/2006 19:19 Aidan Kehoe said the following:
>  Ar an seacht? l? is fiche de m? Deireadh F?mhair, scr?obh Andriy Gapon: 
[snip]
>  > First and the least important:
>  > (key-mapping/info) Undefined Unicode key mappings.
>  > Your keyboard has, among many others, the following keysyms defined:
>  > 
>  >     U20B4 U0301
[snip]
> 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

I'll try this update later. Thank you.

>  > 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 understand your description, but don't understand the origin of the
problem:-) Did those dashes originally appear in chinese charsets ?
Don't some iso8859 charsets have them ?

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

I have my own layouts for Ukrainian and Russian, regular layouts have
poorer repertoire of symbols and do not employ AltGr.
On the other hand, I've just set the standard ua layout and tried to
enter small and capital GHE WITH UPTURN, which is bound to backlash/pipe
key, and I got exactly them, backslash and pipe. At the same time xterm
input was just fine.
So Mode_switch was probably my over-imagination, it seems that XEmacs
falls back either to us layout or some built-in layout.

Maybe I have some problem with my config, here's what I have
(input/unicode related only):

;;unicode support in xemacs-mule
(setq mucs-ignore-version-incompatibilities t) ; xemacs 21.5 with mule
(require 'un-define)
(set-default-output-coding-systems 'utf-8)
(set-coding-priority-list '(utf-8))
(set-coding-category-system 'utf-8 'utf-8)

-- 
Andriy Gapon