Problem with the input of '€' (U+20AC EURO SIGN) with ~/.Xmodmap
Mike FABIAN writes:
When I use that key sequence to type an € in XEmacs, the cursor
advances but I don't see a glyph.
I suppose you wouldn't, as undoubtedly the Greek font hasn't been
updated since Euclid retired. The font may be broken, too (ie, have
an blank glyph there).
When positioning the cursor on that
character and checking with 'C-u C-x =' I get:
€Char: € (U+20AC greek-iso8859-7 36) point=1032 of 1128(91%) column 0
This is undoubtedly due to the fact that ISO 8859/7 is the
lowest-numbered of the ISO 8859 family to encode the Euro sign. I
suppose that the Unicode-to-Mule algorithm searches the loaded
charsets in some order.
I can't get to this for some time.
Aidan, have any ideas offhand? Do you think stuffing ISO 8859/15 in
the search order immediately after ISO 8859/1 would be a good idea and
easy to do?
Why is the Greek charset used when € is input via ~/.Xmodmap?
Some charset has to be used, and XK_CURRENCY is not a charset
available in Mule.
When trying to input ¢ via ~/.Xmodmap, it is even worse, I only get
the regular ASCII 'c' than.
So why doesn't this work with ~/.Xmodmap?
Violate the standard, get what you deserve. The X11 standard for
Unicode keysyms explicitly says that they may not be used for keys
that already have keysyms.
This also applies to EURO SIGN, which has had an X11 named keysym
(XK_eurosign, 0x20AC) for many years.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta