>>>>> "Kenichi" == Kenichi Handa <[EMAIL PROTECTED]> writes:
Kenichi> Thank you for the info, but, oops, it doesn't have these Kenichi> lines (they exist in my debian): ... Kenichi> What's going on here? The diff between revisions 1.2 and 1.3 of that file as seen at: http://cvs.freedesktop.org/xorg/xc/include/keysymdef.h?r1=1.2&r2=1.3 shows several changes from old-style keysyms to unicode keysyms. That checkin replaced all uppercase hex constants with lowercase, added unicode codepoint comments (from UnicodeData.txt), and switched several blocks to the unicode block (0x1000000 to 0x1FFFFFF). The LATIN8 and ARABIC blocks were completely converted and the CYRILLIC block partially converted. Emacs, of course, will need to support both sets -- and any other differences from older versions -- if it wants to support all X servers out there.... Incidently, for anything it doesn't recognize that is: (and (>= 0x1000000 code) (<0x2000000 code)) it can at least insert the ucs character, even if it doesn't know the keysym's name. Perhaps the symbol <UCS_XXXXXX> could be a synonym for the keycode 0x1XXXXXX, for all XXXXXX? >> I'm seeing a similar problem with <Multi_key>. Kenichi> As I'm not European users, I don't know how Multi_key is Kenichi> used. Could you explain the detail of the current problem? Multi_Key is the keysym for the key usually labeled as Compose on the keypad. On a modern PC keyboard, X usually maps the so called menu key to Multi_Key. It initiates a compose sequence, based on the $LOCALE/Compose file. (/usr/X11R6/lib/X11/locale/${LOCALE}/Compose on my Debian box, /usr/lib/X11/locale/${LOCALE}/Compose on my Gentoo box.) ... I just noticed a problem with the X11/locale hierarchy on this box; I'll first have to confirm that the error isn't there. -JimC -- James H. Cloos, Jr. <[EMAIL PROTECTED]> _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel