There is no <compose> sequence for c-acute

[Mario Blažević]

Starting with Ubuntu 11.10, the key sequence Compose+apostrophe+c produces the letter ç (c with cedilla) while the correct one should be ć (c with acute). My compose key is mapped to the right menu key.

The problem is visible in FireFox, Thunderbird, and gedit. Strangely, however, Emacs does it correctly.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Bryce Harrington (bryce)]

On precise I'm getting ç in both firefox and emacs using both compose+apostrophe+c and compose+comma+c.

According to this page, the latter is correct, the former should make c-acute.
http://www.hermit.org/Linux/ComposeKeys.html

However I don't think xkeyboard-config is controlling the compose keys. I think I may have found the source of the error in /etc/console-setup/compose.ISO-8859-1.inc:

compose '´' 'A' to 'Á'
compose '´' 'C' to 'Ç'
compose '´' 'E' to 'É'
compose '´' 'I' to 'Í'
compose '´' 'O' to 'Ó'
compose '´' 'U' to 'Ú'
compose '´' 'Y' to 'Ý'
compose '´' '\'' to '´'
compose '´' 'a' to 'á'
compose '´' 'c' to 'ç'
compose '´' 'e' to 'é'
compose '´' 'i' to 'í'
compose '´' 'o' to 'ó'
compose '´' 'u' to 'ú'
compose '´' 'y' to 'ý'

And in console-setup/Keyboard/locale/iso8859-1:
...
<Multi_key> <acute> <C> : "\307" Ccedilla
<Multi_key> <acute> <c> : "\347" ccedilla
<Multi_key> <C> <comma> : "\307" Ccedilla
<Multi_key> <comma> <C> : "\307" Ccedilla
<Multi_key> <c> <comma> : "\347" ccedilla
<Multi_key> <comma> <c> : "\347" ccedilla
...
<dead_cedilla> <C> : "\307" Ccedilla
<dead_cedilla> <c> : "\347" ccedilla
...
# Useful for portuguese language
<dead_acute> <C> : "\307" Ccedilla
<dead_acute> <c> : "\347" ccedilla

[cousteau (cousteaulecommandant)]

(1) This bug is unrelated to bug #961741, so I request it to be unmarked as duplicate. Bug #961741 is about the inability of typing any deadkey sequence on the program Dash, while this one is about the change of a specific sequence from meaning one thing to meaning another one (while the rest of sequences work fine). Therefore I request this bug report be unmarked as duplicate of bug #961741.

(2) I'm using Xubuntu 12.04, es_ES.UTF-8 locale, and I have the same problem when typing a dead acute followed by 'c'. I expected to get a 'ć' but instead I'm getting a 'ç'. This doesn't happen in my Ubuntu 10.10 nor Lubuntu 10.04 machines.

(3) I've tried copying /usr/share/X11/locale/en_US.UTF-8/Compose to ~/.XCompose, as well as replacing the /usr/share/X11/locale/iso8859-1/Compose and /usr/share/X11/locale/iso8859-1/Compose files with /usr/share/X11/locale/en_US.UTF-8/Compose, with no success.

[cousteau (cousteaulecommandant)]

Ok, I removed the duplicate mark myself (I didn't know I could).

[Gergely Fábián (gergely.fabian)]

This is reproducible on Ubuntu 12.10 amd64 with firefox, terminal and gedit (with Hungarian keyboard layout). However in Skype dead_acute + c produces "ć".
Is there any workaround for this problem?
Thanks.

[Gergely Fábián (gergely.fabian)]

I guess I may have found a workaround.
I use Hungarian keyboard layout with hu_HU.UTF-8 locale and I'd like to type the "ć" character with AltGr+9+c (dead_acute+c) (used in Polish and Croatian/Serbian).
I have been googling and experimenting quite long to find a workaround with no success. The most interesting point was, that the file that most claimed needs the changes already contains the proper entries:

/usr/share/X11/locale/en_US.UTF-8/Compose

<dead_acute> <C> : "Ć" U0106 # LATIN CAPITAL LETTER C WITH ACUTE
<Multi_key> <acute> <C> : "Ć" U0106 # LATIN CAPITAL LETTER C WITH ACUTE
<Multi_key> <apostrophe> <C> : "Ć" U0106 # LATIN CAPITAL LETTER C WITH ACUTE
<Multi_key> <C> <apostrophe> : "Ć" U0106 # LATIN CAPITAL LETTER C WITH ACUTE
<dead_acute> <c> : "ć" U0107 # LATIN SMALL LETTER C WITH ACUTE
<Multi_key> <acute> <c> : "ć" U0107 # LATIN SMALL LETTER C WITH ACUTE
<Multi_key> <apostrophe> <c> : "ć" U0107 # LATIN SMALL LETTER C WITH ACUTE
<Multi_key> <c> <apostrophe> : "ć" U0107 # LATIN SMALL LETTER C WITH ACUTE

I tried changing other files as well:

- /etc/console-setup/compose.ISO-8859-1.inc (I changed the lines combining dead_acute with c to result in "ć" instead of "ç", but it did not help)
- adding a ~/.XCompose with the proper entries (but what for, if en_US.UTF-8/Compose already contains the proper entries?)

As a last act of desperation, basing on a hint I found at http://wiki.linuxquestions.org/wiki/Accented_Characters I tried adding "GTK_IM_MODULE=xim" to /etc/environment. This finally helped.
Then I reverted all my previous changes (left just the one in /etc/environment), and entering "ć" is still possible.
However now I see other problems with the input method (Ctrl+F doesn't work in gedit - when the IM_MODULE is not xim it works properly), so I wouldn't like to use this "hack".

So my questions are:
- Why are the settings in /usr/share/X11/locale/en_US.UTF-8/Compose not taking any effect with the default input method? (my /usr/share/X11/locale/compose.dir defines en_US.UTF-8/Compose for hu_HU.UTF-8, so it should take effect)
- Why are those settings taking effect in turn when the input method is xim?
- What is the default input method (I guess it's not xim), and where are those "Compose" settings that should take effect for it?

[Gergely Fábián (gergely.fabian)]

One more short comment. Another "workaround": you may always insert the "ć" and "Ć" chars by pressing Ctrl+Shift+u and then typing the appropriate unicode codes (0106 for "Ć" and 0107 for "ć").

[Mario Blažević (blamario)]

I gave up a while ago. One thing that may be of interest is that Linux Mint Debian Edition, update pack 6, does not suffer from the bug. It appears that this is Ubuntu's problem only, it's not coming from upstream Debian.

[Joakim Ekberg (j-a-o)]

Do we even know what the intended behaviour is? As it is now, we have:

dead_acute + c => ç
dead_grave + c => [nothing]
compose + apostrophe + c => ç
compose + comma + c => ç

Three ways to type ç (perhaps AltGr-, works too on some layouts), and none to type a c with an acute accent. That certainly cannot be intended behaviour! At the least, I think having compose + apostrophe + c as a needless duplication of compose + comma + c makes no sense.

Just to be clear, there are no satisfactory alternatives:
- Changing keyboard layout is not an option: just because I occasionally want to write a Croatian name (for instance), doesn't mean I can write Croatian nor that I am familiar with the Croatian keyboard layout. If I had to do it to be able to type any of the letters, that would be different, but all the others are right there, along with the Czech, Polish, Hungarian, Danish letters etc—and ç (I need ç too, but I don't need to type it in three ways…).
- Memorizing numerical codes is something I had to do on Windows, and I would prefer to have left that behind me.
- Fábián's workaround looked interesting but I haven't tried it, for fear of the flaws he found in it.

[Mario Frasca (mfrasca)]

bug #518056 might be related: it describes the correct behaviour as undesirable.
since no action is associated to that report, it's not clear what has happened in between.

[Mario Frasca (mfrasca)]

this is an old message, but still seems related:
https://mail.gnome.org/archives/gtk-i18n-list/2003-October/msg00002.html

[Mario Frasca (mfrasca)]

I filed a bug report upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=694427

[Mario Frasca (mfrasca)]

I modified the title. maybe it is more obvious this way that this problem has no easy workaround.

[Frederik Elwert (frederik-elwert)]

I just discovered a work-around that is easier than setting an environment variable (GTK_IM_MODULE), but effectively does the same: In the text field where you want to type, e.g. gedit, right-click and select “Input Methods → X Input Method” from the context menu.

So this behavior seems to stem from the default input method, IBus. This might explain why editing the files under /usr/share/X11 had no effect. So maybe this bug is not affecting console-setup, but IBus instead? Or does anyone know where the pre-configured IBus input method gets its mappings from?

[Mario Frasca (mfrasca)]

people affected by this bug, would you please comment upstream?
https://bugzilla.gnome.org/show_bug.cgi?id=705168
there seems to be no interest around the issue there.

[Mario Frasca (mfrasca)]

I have contacted the author of this (https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=d270a00d) commit, hoping he can help us understand what steps we should take to solve this bug.

[Carlos Andrade (carlos-andrade)]

(Copy paste from https://bugzilla.gnome.org/show_bug.cgi?id=705168#c9)

I can confirm this behavior with im-ibus.

Problem appears because ibus-1.4.2/client/gtk2/ibusimcontext.c & gtk3/ibusimcontext.c include verbatim copies of imcedilla around line 533.

I guess other input methods have been corrupted with the same "fix". Check http://crosbug.com/11421 for details.

The main problem here is GTK using a hardcoded table to compose characters. There is no way to have a per-locale translation for key sequences.

A few solutions come to my mind (from dirtier to cleaner):

* Fix ibus and another input methods so they have a user-defined variable (gconf) to determine cedilla behavior.
* Fix ibus and other input methods so only languages that use "imcedilla.so" (from gtk.immodules and immodules.cache) get dead_acute + c = ç.
* Fix GTK+ to allow runtime definition of key sequences. Remove imcedilla.so and ccedilla table from all input methods.

[Adrianna Pińska (confluence)]

This is *still* a problem for me, two years later, in a fresh install of 16.10. I get the correct compose sequence in Qt apps, but not in GTK apps. The workaround of setting GTK_IM_MODULE=xim still appears to work.

Is any attempt being made to fix this? The upstream bug appears to have been "resolved" as "not a bug". GTK apps are currently effectively unusable for typing Polish out of the box (unless you change the keyboard layout, which is not an acceptable solution for users of US-layout keyboards who use multiple languages).

[Adrianna Pińska (confluence)]

Addendum for anyone else coming across this thread: for the workaround, I have added `export GTK_IM_MODULE=xim` to `~/.xprofile`. Environment values exported in `.bashrc` will not be applied to the graphical environment, and therefore will not affect apps launched from the GUI.