In /usr/share/X11/locale/en_US.UTF-8 is the Compose file for English. It lists the Compose key sequences, and the permitted uses for dead and combining keys. It used to be possible to customise it, which was very useful for linguists or mathematicians. Now altering it or even removing it has no effect. So where are the sequences being obtained? This is presumably a Gnome thing, but a post at Gnome support has obtained no answer. Can anyone shed any light on this? (Or even on why one can never find any documentation about Gnome )

Try to add the following line in /etc/X11/xorg.conf in the keyboard (input device) section:
then restart the X server. It enables the Right Windows key as the compose key.

PS: you can enable it also from the system menu: System -> Preferences -> Keyboard -> Layout Options -> Compose key position.

Oh, dear

I didn't ask how to enable a compose key. Please read the question before asking it: if you answer the wrong question, it removes the thread from the zero-replies category and so reduces the chance of it ever getting answered.

Sorry, that was not my intention... errare humanum est.

To activate your custom compose sequence you have to define an environment variable:
if using Gnome, whereas using KDE it should be QT_IM_MODULE=xim. There are different opinions on where to put such definition, however it works if you put it in your own ~/.bashrc. After that, restart the X server and the changes in /usr/share/X11/locale/en_US.UTF-8/Compose should take effect.

If you want to leave the system file unchanged, you can create the file ~/.XCompose and include /usr/share/X11/locale/en_US.UTF-8/Compose together with your custom sequences. For example:
Hope this helps, now.

I already have GTK_IM_MODULE=xim in /etc/environment, and "echo $GTK_IM_MODULE" shows that it's set. Without this, some compose sequences work, some don't.

As I said, the problem here is that a set of definitions identical to the one in the default file is being obtained from somewhere other than the default file, and I can't trace the source. I suspect that it must be compiled-in somewhere, completely negating the whole Linux idea of having configuration files accessible to the user.

Further research shows that the problem is that, despite setting the environment variable, xim is not working, and GTK then falls back on a hard-wired default of an old US compose sequence. The cure is another question.

Googlin' around I found that X input method is different from GTK+ input method, which is the default. I wouldn't tell it's not working, it just works in a different way, with different compose sequences. Furthermore it does not accept unicode sequences, those obtained by Ctrl-Shift-U + code.

Here is a little explanation about input methods, with some other interesting links. It's hard to find information about the inner mechanism involved in compose sequences. Indeed, it looks like it is hard-coded in the GTK2 library. I tried to grep GTK_IM_MODULE and the unique result is libgtk-x11-2.0.so.0.1000.4 which is provided by gtk2-2.10.4-20.el5 (this is CentOS 5.3).

Thanks for the link. The problems seem to be

1. Setting the environment variable is no longer working in Fedora, though it used to, and still does in Ubuntu. I shall try reporting that as a bug.

2. The Gnome people insist on hard-wiring something which ought to be configurable, and duplicating something that is already there.

In Fedora you need to set GTK_IM_MODULE=xim in /etc/X11/xinit/xinput.d/none.conf, you also need to install the gtk2-immodule-xim package

solution from here:

http://forums.fedoraforum.org/showthread.php?t=226805