Red Hat Bugzilla – Bug 168739
dead_diaeresis + space maps to diaeresis
Last modified: 2007-11-30 17:11:13 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b4) Gecko/20050915 Fedora/1.5-0.5.0.beta1 Firefox/1.4 Description of problem: On all X11 and GTK+ applications, dead_diaeresis (my " key) followed by a blank generates ", whereas dead_diaeresis typed twice generates a diaeresis. On XEmacs, this doesn't work as expected. The first sequence generates a diaeresis character, whereas repeatedly entering dead_diaeresis has no effect, until you type a different character, at which point it says a long sequence of dead_diaeresis followed by that character is not mapped to any sequence. All other X compose sequences seem to be working correctly. As it stands, I couldn't enter the quote character without adding the following hack to my .emacs: (global-set-key '(diaeresis) (lambda () (interactive) (self-insert-internal ?\"))) Version-Release number of selected component (if applicable): xemacs-21.4.17-4 iiimf-12.3.91 How reproducible: Always Steps to Reproduce: 1.Start an X session using the us-intl keyboard layout 2.Start xemacs -no-init-file on an X session 3.Enter " (dead_diaeresis event generated) followed by a blank 4.Enter "" (dead_diaeresis twice) Actual Results: I got ¨ for 3., and nothing for 4., until I typed something else and got an error. Expected Results: 3. should generate ", and 4. should generate ¨, like all other X and GTK+ applications do, including GNU Emacs. Additional info:
Note: XEmacs as shipped in Extras is not using GTK+ (because the GTK+ port is not ready for prime time). Anyway, on my setup (LANG=en_US.UTF-8 or LANG=en_US, LC_ALL and LC_CTYPE unset, iiimf not installed) with XEmacs running under KDE, I get the expected results from your test case. What are your LC_ALL, LC_CTYPE and LANG environment variables set to? (See /usr/share/xemacs/site-packages/lisp/site-start.el.)
Do you actually select the us-intl keyboard layout, that generates dead_diaeresis when you press " ? I have LANG=en_US.UTF-8, LC_ALL and LC_CTYPE unset. Oddly, if I start xemacs -no-site-file, then dead_diaeresis space does generate ", as expected. Surprisingly, xemacs -vanilla fails in the same way. I've run these new tests after uninstalling iiimf and rebooting. The problem happens consistently on both IA32 and AMD64, running both within gnome and within a failsafe session, with xemacs started running on a local display, as well as on a ssh-tunneled display.
Doh, nevermind the comment above about -vanilla failing and -no-site-file working; that's because -vanilla disabled loading my .emacs where I'd introduced the work-around. Doh!
The problem occurs on both FC4 and devel, BTW.
With LANG=en_US xemacs -vanilla -no-autoloads -no-early-packages, dead_diaeresis space self-inserts a "; with LANG=en_US.UTF-8, it self-inserts a ¨. C-h k says the key sequence maps to self-insert-command in both cases, so there's some lower-level layer of xemacs that's incorrectly mapping the compose sequences. strace shows it opens the locale Compose files before looking at site-start.el* files, which appears to support this conclusion. Anyhow, if you look at the Compose files for ISO8859-1 and en_US.UTF-8, you'll see that they both have the same compose rules for dead_diaeresis space and dead_diaeresis dead_diaeresis, so that does not explain why it gets it wrong.
On rawhide, dead_diaeresis blank now generates a ", as intended, even though I haven't changed XEmacs at all. However, any other non-ASCII character can't be entered directly any more: dead_acute a, for instance, generates the error `U00E1 not defined' on both FC 4 and devel. This is all with LANG=en_US.UTF-8. If I switch to LANG=en_US, then everything works fine, but it's a bit of a pain to have to special-case xemacs to run in the wrong locale. Its UTF-8 compatibility is already lacking in some regards, and I guess telling it to run in a non-UTF-8 default encoding won't make it any better... Anyhow, any ideas of where the behavior change came from, and whether there's any hope for XEmacs to accept non-ASCII UTF-8 characters from X again?
From what I gather from upstream discussions (and to some extent experience), UTF-8 support is indeed not too good in the 21.4.x series, and almost certainly will never be. For some possibly related info, see bugs #127797, #157534 and https://bugs.freedesktop.org/show_bug.cgi?id=3392 Also, here's one thing you might want to try out (if you do, let me know how it goes): http://list-archive.xemacs.org/xemacs-beta/200505/msg00113.html Anyway, I hear the 21.5.x series of XEmacs is actually in a pretty decent shape nowadays and should have vastly improved Unicode support. SuSE (at least in OpenSuSE) has upgraded to it already some time ago. I may look into doing the same in the not-so-distant future.
This bug hasn't been updated in a long time and targets FE devel. Could you please check that it still occurs with current FE devel and update accordingly ? Thanks.
This works with XEmacs as in Fedora 6.