Bug 168739 - dead_diaeresis + space maps to diaeresis
dead_diaeresis + space maps to diaeresis
Product: Fedora
Classification: Fedora
Component: xemacs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2005-09-19 17:54 EDT by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-19 02:31:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2005-09-19 17:54:43 EDT
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:

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:
Comment 1 Ville Skyttä 2005-10-03 15:53:40 EDT
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.)  
Comment 2 Alexandre Oliva 2005-10-04 20:32:26 EDT
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.
Comment 3 Alexandre Oliva 2005-10-04 20:40:17 EDT
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!
Comment 4 Alexandre Oliva 2005-10-04 20:44:17 EDT
The problem occurs on both FC4 and devel, BTW.
Comment 5 Alexandre Oliva 2005-10-05 00:02:36 EDT
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
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.
Comment 6 Alexandre Oliva 2005-11-10 11:43:38 EST
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?
Comment 7 Ville Skyttä 2005-11-10 12:42:03 EST
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  
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. 
Comment 8 Christian Iseli 2007-01-19 02:22:19 EST
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 ?

Comment 9 Alexandre Oliva 2007-01-19 02:31:32 EST
This works with XEmacs as in Fedora 6.

Note You need to log in before you can comment on or make changes to this bug.