In article <[EMAIL PROTECTED]>, James Cloos <[EMAIL PROTECTED]> writes:
>>>>>> "Kenichi" == Kenichi Handa <[EMAIL PROTECTED]> writes: Kenichi> It seems that these X11 keysyms (in Kenichi> /usr/include/X11/keysymdefs.h, perhaps newly added) are not Kenichi> registered in x-keysym-table (in lisp/term/x-win.el). > For the Cyrillic, see /usr/include/X11/keysymdef.h on a current > install, or online at: > http://cvs.freedesktop.org/xorg/xc/include/keysymdef.h?rev=1.3&view=markup > It has unicode values for each keysym that is in unicode. (And note > that for any keysym that matches (and 0x01000000 keysym) the unicode > codepoint can be found by (and 0xFFFFFF keysym). Thank you for the info, but, oops, it doesn't have these lines (they exist in my debian): #define XK_Cyrillic_GHE_bar 0x680 [...] #define XK_Cyrillic_u_macron 0x69f but have: #define XK_Cyrillic_GHE_bar 0x1000492 /* U+0492 CYRILLIC CAPITAL LETTER GHE WITH STROKE */ [...] #define XK_Cyrillic_u_macron 0x10004ef /* U+04EF CYRILLIC SMALL LETTER U WITH MACRON */ What's going on here? Anyway, as it's easy to handle them in emacs-unicode-2, I've just commited a code for that for emacs-unicode-2. > I'm seeing a similar problem with <Multi_key>. > It works for every app other than Emacs. > I don't know whether it is a regression; I only tried it becuase > quail was broken in emacs-unicode-2 of a few days ago (since fixed). > I would be useful if X's standard compose feature were usable in > emacs. Or, OTOH, perhaps it would make a good alternate first > stroke for the quail methods like rfc1345, sqml, latex, etc. As I'm not European users, I don't know how Multi_key is used. Could you explain the detail of the current problem? --- Kenichi Handa [EMAIL PROTECTED] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel