From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 Description of problem: Various applications, such as openoffice, dia, emacs, do not accept entry of accented characters via a compose sequence (compose key, character, accent). I have found bash and gedit to be the only applications that correctly work Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Choose a compose key. Mine is keycode 117 = Multi_key, set with xmodmap 2. Graphical log in, tried US, British, Dutch, Spanish with all the same result 3. Check compose key sequence in bash -> correct 4. Open [emacs|openoffice|dia] and try the same compose key again. Actual Results: Nothing Expected Results: Accented character Additional info: ad 4: I did define a SAL_ALTGR_COMPOSE (IIRC the name of the beast) environment variable Pasting a composed character made in bash results in two (different) characters in the target application.
The bug only occurs when in a UTF-8 locale. A workaround is explicitly giving the locale as a non-UTF-8 locale, by adding export LANG=en_US to .bash_profile. For having the same locale in a terminal window, I had to add the same to .bashrc ???
I seem to be having the same kind of problem with danish chars - they just does not get on the screen when pressed - that's f, x and e (i'm on en_DK.UTF-8 locale)
[using an US-kbd, need to enter French & German accents in both en_US* and fr_CH* locales] With the proper X-config and selecting "us" (compose-key) or "us-international" (dead keys) in the keyboard applet, it mostly works (not the case with the default keyboard). For OpenOffice and Mozilla, I had to add LANG=${LANG%.UTF*} in the wrappers (assumes minimal ksh-syntax support in /bin/sh and no use of LC_* env vars)
*** Bug 82895 has been marked as a duplicate of this bug. ***
I'm not able to reproduce with the latest OOo in rawhide. Please try that one and reopen if necessary.