Simos, do you consider this a deficiency of the X compose file, too ?

It should be simple enough to check Multi_key <foo> <bar> both ways...

Created attachment 122516 [details] [review]
a possible patch

Matthias, suppose there are two sequences (hypothetical scenario)

<Multi_key> <minus> <greater> : "↣"
<Multi_key> <greater> <minus> : "↢"

then it would be an issue if these are transposed.

Additionally, it might be useful in the future to allocate sequences such as 

<Multi_key> <m> <e> : "€"  # Euro
<Multi_key> <m> <r> : "₨" # Indian Rupee
<Multi_key> <m> <w> : "₩"  # Korean Won
<Multi_key> <m> <s> : "₪"  # Israeli Sheqel
<Multi_key> <m> <w> : "₩"  # Korean Won

so that whatever sequence starts with <Multi_key> <m> is related to money/currency. Therefore, <Multi_key> <some_letter> should be used sparingly.

The current state of affairs with compose sequences at X.Org is that there is no immediate initiative to specify compose sequences for all those special Unicode characters.

These are my concerns and I have not communicated with X.Org for more input yet. 

What I would like to do is write a script that would traverse the Compose file, find all sequences that start with <Multi_key> and have length 3, and check if there are conflicts when we switch place for keys 2 and 3 in the sequence.

Fair enough. 

Even though, in your first hypothetical example, both sequences would be in the table, so the flipping would never occur...

Makes it more pressing to support a second Compose file, so that we can add the reversed sequences manually, until the X.org Compose file has them. 

On the other hand, looking at the X.org compose file, there is 
1645 sequences of length 3 starting with Multi_key, which is a lot to add reverse sequences to the table for. Even restricting to sequences yielding latin characters, it is still 621 sequences.

I think my algorithmic approach could be make to work well enough by restricting it to sequences whose middle key is a typical accent like

acute 
apostrophe
asciicircum
asciitilde
cedilla
comma
equal
exclam
grave
macron
minus
period
question
quotedbl
semicolon
slash
underscore

Created attachment 122764 [details]
List of old gtk compose sequences that are not found in X.Org's list. 

This is the list of compose sequences that used to exist in gtk+ but are not there anymore because we have synced with upstream/X.Org.

It's a big list with over 400 items.

I've recently upgraded to GTK+ 2.14, and since then I can't type various characters I use from time to time, e.g. the middle dot (·) and ř (for instance Dvořák).

What's the plan? Perhaps manually adding some of these sequences, especially the latin characters with diacritical marks?

I must admit this was very jarring. This is filed as a GTK bug, of course, but it's a massive impact one people who were previously productive on their GNOME desktops.

(Virtually none of the <Compose> sequences I was used to using work anymore, and in most cases I haven't been able to figure out an alternative. It's pretty much reached the point where I don't bother with Compose now and find myself having to run the character map program all the time now instead. A bit of a shame, really - I was quite fond of my Compose key sequences and they're still in my fingers)

AfC

Andrew, Wouter, did you find the compose sequences that you see missing in the attached file (see comment #6)? 

Yeah, my favourites are all there. I suppose that isn't surprising. [assuming that "<Multi_key>" and what I consider <Compose> (as defined by gnome-keyboard-properties) are the same]

Over and above the ones "missing" is the more general question of why order is important. I was used to doing  <Compose>a' to get á, but now have to do <Compose>'a. I mean, sure, {shrug}, but... Not sure why it's taking me so long to learn that.

As for why things like <Compose>l= for £ and <Compose>0* for ° went away, I'm at a loss, but as I'm not the one writing the code, I can only quietly register my experience as a user and hope that perhaps someone will tell me how I should be doing things better.

AfC

Simos, I think this is one of the higher-priority bugs to fix in the stable branch, so if you have time to look into adding lookaside-file support to your scripts that would be awesome.

Created attachment 123401 [details] [review]
Patch to gtkimcontextsimpleseqs.h (branch: gtk-2-14) that adds back 'legacy' gtk+ compose sequences

Patch 1 of 2.

Adds back compose sequences that were implicitly removed due to the synch with upstream (X.Org does not have these sequences anymore)

Created attachment 123402 [details] [review]
(2/2) Patch to gtkimcontextsimple.c, updates to match content in gtkimcontextsimpleseqs.h

(In reply to comment #9)
> Andrew, Wouter, did you find the compose sequences that you see missing in the
> attached file (see comment #6)? 

Same fore me. And they seem also to be in your patch, e.g. ř (U+0159) is in there: 'GDK_r, GDK_less, 0x0159'

*** Bug 559909 has been marked as a duplicate of this bug. ***

Created attachment 123412 [details]
List of legacy gtk+ compose sequences that went missing when we synched with X.Org's Compose

This is the extracted file of compose sequences that used to exist in gtk+ up to gtk-2-12, and are missing from the upstream (XOrg) Compose file.

This file can be used when refreshing the gtkimcontextsimpleseqs.h table.
The updated compose-parse.py script merges this file and the upstream Compose file.

Those patches look good to me. Please commit the updated compose-parse script and the lookaside file together with them. We should also update the comment at the top of gtkimcontextsimpleseqs.h to mention the lookaside.

Finally, we should probably file one or more bugs to get some of these missing sequences into the x.org compose file. That raises the related question, does compose-parse warn if there is overlap between the two input files ?

Here are the 15 conflicts (resolved in favour of gtk+ legacy sequences):

--- gtkimcontextsimpleseqs.h.ORIGINAL	2008-11-27 21:39:05.000000000 +0000
+++ gtkimcontextsimpleseqs.h	2008-11-27 22:14:06.000000000 +0000
--
-GDK_exclam, GDK_S, 0x1E62, 
+GDK_exclam, GDK_S, 0x00A7, 
--
-GDK_exclam, GDK_s, 0x1E63, 
+GDK_exclam, GDK_s, 0x00A7, 
--
-GDK_comma, GDK_E, 0x0228, 
+GDK_comma, GDK_E, 0x0118, 
--
-GDK_comma, GDK_e, 0x0229, 
+GDK_comma, GDK_e, 0x0119, 
--
-GDK_period, GDK_period, 0x2026, 
+GDK_period, GDK_period, 0x02D9, 
--
-GDK_slash, GDK_C, 0x20A1, 
+GDK_slash, GDK_C, 0x00A2, 
--
-GDK_equal, GDK_L, 0x20A4, 
+GDK_equal, GDK_L, 0x00A3, 
--
-GDK_L, GDK_equal, 0x20A4, 
+GDK_L, GDK_slash, 0x0141, 
--
-GDK_asciicircum, GDK_0, 0x2070, 
+GDK_asciicircum, GDK_0, 0x00B0, 
--
-GDK_underscore, GDK_A, 0x0100, 
+GDK_underscore, GDK_A, 0x00AA, 
--
-GDK_underscore, GDK_O, 0x014C, 
+GDK_underscore, GDK_O, 0x00BA, 
--
-GDK_underscore, GDK_o, 0x014D, 
+GDK_underscore, GDK_o, 0x00BA, 
--
-GDK_c, GDK_O, 0x01D1, 
+GDK_c, GDK_O, 0x00A9, 
--
-GDK_c, GDK_o, 0x01D2, 
+GDK_c, GDK_o, 0x00A9, 
--
-GDK_d, GDK_minus, 0x20AB, 
+GDK_d, GDK_minus, 0x0111, 

Committed to gtk-2-14.

        Bug 557420 – Some compose sequences don't work anymore (or only in 
        a specific order)
        
        * gtk/gtkimcontextsimple.c: Update of table size, keysym boundary,
        to match the gtkimcontextsimpleseqs.h table.
        * gtk/gtkimcontextsimpleseqs.h: Update with older gtk+ compose
        sequences that went missing due to table update with upstream.
        * gtk/compose-parse.py: Updated to include gtk-compose-lookaside.txt
        * gtk/gtk-compose-lookaside.txt: Older gtk+ compose sequences that
        are not found in the X.Org Compose file.

To commit to trunk shortly.

Bug report at FDO relating to these compose sequences,

«Add compose sequences from gtk+ to X.Org»
https://bugs.freedesktop.org/show_bug.cgi?id=18751

Simos, have you fixed this in trunk as well? If so, is there a reason this bug report is still open?

(In reply to comment #21)
> Simos, have you fixed this in trunk as well? If so, is there a reason this bug
> report is still open?
> 

Applied to trunk as well, closing report.

I applied the following patch to branch gtk-2-14,

--- gtkimcontextsimple.c.ORIGINAL	2008-12-04 00:37:53.000000000 +0000
+++ gtkimcontextsimple.c	2008-12-04 00:37:07.000000000 +0000
@@ -415,7 +415,7 @@
  * In future versions it will be just the keysym (no +1).
  */
 #define IS_DEAD_KEY(k) \
-    ((k) >= GDK_dead_stroke && (k) <= (GDK_dead_dasia+1))
+    ((k) >= GDK_dead_grave && (k) <= (GDK_dead_dasia+1))
 
 static gboolean
 check_algorithmically (GtkIMContextSimple    *context_simple,


Reasoning: dead_stroke is not the lower bound among the values of dead keys.
dead_grave still has the lowest value. The problem arose because dead_stroke is a recent addition, and was added manually in compose-parse.py with the Unicode value. So, when sorting, dead_stroke appeared on top because the Unicode value is much lower than the typical keysym values for dead keys (around 0xF5xx).

By updating the gdk/gdkkeysyms.h and gtk/gtkimcontextsimple.c to the latest in X.Org, we are able to remove those hard-coded values in the conversion script.

Simos, it seems that <Compose> . . produced a … (ellipsis) in 2.14.5, and ˙ (high dot) in 2.14.7. IIRC the high dot was also produced in 2.12.x (but I'm not sure). The ellipsis behaviour was really useful, but now it's gone again, in between point releases of the *stable* series :(  Any clue why?

Additionally, some sequences are masked by others, e.g.

  GDK_parenleft, GDK_a, 0x0103,

masks

  GDK_parenleft, GDK_a, GDK_parenright, 0x24D0, 

Note that these sequences come from trunk, not gtk-2-14: http://svn.gnome.org/viewvc/gtk%2B/trunk/gtk/gtkimcontextsimpleseqs.h?revision=21843&view=markup

Wouter, the 

<Multi_key> <period> <period> 

compose sequence is indeed masked by the legacy compose sequences that have been inserted with the file
http://svn.gnome.org/svn/gtk%2B/trunk/gtk/gtk-compose-lookaside.txt

The source of the problem is that there are conflicts between what the current X.Org compose file contains, and the compose sequences that GTK+ used to have (and where added many years ago).

The proper solution would be to handpick the compose sequences from gtk-compose-lookaside.txt that we really want to keep.

An easy workaround would be to change the priority when mixing the compose sequences from X.Org and gtk-compose-lookaside.txt, so that X.Org sequences are prefererred when a conflict arises. This would still need some final handpicking, and would require to come back in the future when sequences are added to X.Org.

With the re-introduction of these legacy compose sequences a number of characters have been effectively removed from the compose tables due to redundant legacy compose sequences. I was rather surprised to find I couldn't enter the characters I need for transliterated Japanese (Hepburn system) any more after upgrading to the latest Gnome last week. This effectively reopens bug 334075 for me.

The missing characters that directly affect me are:

minus + o = ō
minus + O = Ō
minus + a = ā
minus + A = Ā

They are present upstream, but are replaced by legacy sequences giving me ã, Ã, õ and Õ.

The upstream alternative was:

underscore + o = ō
underscore + O = Ō
underscore + a = ā
underscore + A = Ā

But these have been replaced by º, º, ª and ª.

The other macron vowels still work for both sequences: ē, Ē, ī, ī, ū, Ū. The y is a bit different:

minus + y = ¥
minus + Y = ¥
underscore + y = ȳ
underscore + Y = Ȳ

Although to be frank, that is one letter I don't actually need, but for the sake of consistency I mention it.

A good review of all legacy compose sequences seems necessary, especially if they add an extra sequence for existing characters at the cost of other characters. My suggestions for characters that I know about and use on a daily basis follow.

In the absence of a macron key (i.e. most keyboards), the upstream file seems to standardise on <underscore> for the vowels with macron characters. For the 12 characters mentioned above (6 vowels and their capitals) this means that the º and ª legacy sequences are conflicting with them:

<Multi_key> <O> <underscore> 			: "º" U00BA
<Multi_key> <underscore> <O> 			: "º" U00BA
<Multi_key> <underscore> <o> 			: "º" U00BA
<Multi_key> <o> <underscore> 			: "º" U00BA
<Multi_key> <A> <underscore> 			: "ª" U00AA
<Multi_key> <underscore> <A> 			: "ª" U00AA
<Multi_key> <underscore> <a> 			: "ª" U00AA
<Multi_key> <a> <underscore> 			: "ª" U00AA

Now looking at the upstream compose table, I see that in turn their original sequence is overridden by the legacy table too:

Original:

<Multi_key> <asciicircum> <underscore> <o>
<Multi_key> <asciicircum> <underscore> <a>
(there are more, but they involve non-standard keys)

These are overridden by the legacy:

<Multi_key> <asciicircum> <underscore> 			: "¯" U00AF

Which blocks all those three-character sequences starting with <asciicircum> <underscore>.

Proposal for resolving this matter:

U00AF (¯):
I suggest offering upstream / keep in legacy table:
<Multi_key> <underscore> <underscore>
This sequence is unclaimed, and seems logical.

Drop from legacy table:
<Multi_key> <asciicircum> <minus>
<Multi_key> <asciicircum> <underscore>
<Multi_key> <underscore> <asciicircum>

U00AA (ª) and U00BA (º):
Drop from legacy table:
<Multi_key> <A> <underscore>
<Multi_key> <underscore> <A>
<Multi_key> <underscore> <a>
<Multi_key> <a> <underscore>
<Multi_key> <O> <underscore>
<Multi_key> <underscore> <O>
<Multi_key> <underscore> <o>
<Multi_key> <o> <underscore>
Use the upstream sequences, or ask someone who uses these characters to suggest an (unclaimed!) alternative sequence.

This proposal leaves the <minus> <vowel> sequences in the legacy file. I don't like them at all as they encourage counter-intuitive compose sequences, but they do not seem to conflict with other upstream sequences, and map to fairly common characters in Roman languages.

Personally, I would recommend eventually moving away from this legacy file, and pushing any useful sequences upstream rather than running the risk of overriding existing upstream sequences.

(In reply to comment #26)
> Wouter, the 
> 
> <Multi_key> <period> <period> 
> 
> compose sequence is indeed masked by the legacy compose sequences that have
> been inserted with the file
> http://svn.gnome.org/svn/gtk%2B/trunk/gtk/gtk-compose-lookaside.txt

I like the … too, so might I suggest an alternative for this legacy sequence?

Drop from legacy table:
<period> <period>
This gives us the upstream U2026 … (horizontal ellipse) back.

Push to upstream / put in legacy table:
<asciicircum> <period>
This is a new unclaimed sequence that seems logical: ^ (up) . (period) gives abovedot U02D9 (˙). It is currently only available using uncommon keys (<dead_abovedot>) upstream.

Created attachment 133801 [details]
Conflicting compose sequences defined by both GTK+ legacy and X.Org compose tables

This is a list of conflicting compose sequences comparing today's versions of the GTK+ legacy and X.Org compose tables.

17 sequences conflict.
4 sequences are redundant (generate the same character) and can (and probably should) be removed from the GTK+ file without consequences.

A word of caution:
This file does not list the conflicts that occur when a shorter sequence in the GTK+ table overrides a longer X.Org sequence, such as the case of "<Multi_key> <asciicircum> <underscore>" versus "<Multi_key> <asciicircum> <underscore> <a>".

(I noted this also over on Bug 155010 [http://bugzilla.gnome.org/show_bug.cgi?id=155010#c7])

Using Gnome 2.26.1 on Ubuntu 9.04 (Jaunty).

To ditto Jeroen Hoek, and as Carl Bergquist notes in Bug 155010, the GTK compose key sequences for macrons are inconsistent:

compose + - + a -> ã
compose + - + i -> ī
compose + - + u -> ū
compose + - + e -> ē
compose + - + o -> õ

compose + _ + a -> ª
compose + _ + i -> ī
compose + _ + u -> ū
compose + _ + e -> ē
compose + _ + o -> º

Given that there already exists a separate perfectly good compose sequence for
adding a tilde (compose + ~ + <vowel>), I am more than a little baffled why the
above inconsistency exists.  This is poor usability, and I strongly request
that the compose key sequences for macrons be unified, such that compose + - or
_ + <vowel> properly outputs that vowel with a macron.  Different behaviour for
different vowels is confusing and unacceptable.  

Jeroen, Eiríkr,

GTK+ follows the compose sequences that are specified upstream, with the exception of the old legacy GTK+ compose sequences that override, and are listed in 
http://git.gnome.org/cgit/gtk+/tree/gtk/gtk-compose-lookaside.txt
AFAIK, GNOME 2.24 did not have the legacy table while GNOME 2.26 does.

Could you please provide a patch on
http://git.gnome.org/cgit/gtk+/tree/gtk/gtk-compose-lookaside.txt
that removes those compose sequences that conflict with upstream and break uniformity?

The two issues we need to counter here are the expectations of the old GNOME (up to GNOME 2.22) users that are used to the legacy GTK+ compose sequences, and the new GNOME (GNOME 2.24, also those non-GTK+ users) users.

My personal preference would be to follow X.Org, when conflicting or non-uniform compose sequences occur, and at the same time publicize this in release notes, blog posts, etc so that users make the switch in an informed way.

Created attachment 134886 [details] [review]
Replacing the <minus> compose sequences that previously produced tilde-modified 'a' and 'o' to instead produce macron-modified 'a' and 'o' (lowercase only; uppercase sequences already exist)

This is my first-ever patchfile (yay!), so please alter / comment / etc. as appropriate.

Created attachment 134887 [details] [review]
Replacing the <minus> compose sequences that previously produced tilde-modified 'a' and 'o' to instead produce macron-modified 'a' and 'o' (lowercase only; uppercase sequences already exist)

This is my first-ever patchfile (yay!), so please alter / comment / etc. as appropriate.

Created attachment 134889 [details] [review]
Resolve compose sequence conflicts with upstream X.org

This patch removes conflicting sequences in favour of upstream X.org.

Eiríkr:
I have added your <Multi_key> <minus> sequences in this patch as well, you forgot to change the Unicode number after the character.

For future reference, I have commented on the removed sequences below:

<Multi_key> <asciicircum> <0>
Consistency. <Multi_key> <asciicircum> [1..9] gives the superscript digit, legacy sequence for zero is inconsistent.

<Multi_key> <c> <o> 
<Multi_key> <c> <O>
Consistency. <Multi_key> <c> [:letter:] already gives vowel plus caron, legacy sequence for c is inconsistent.

<Multi_key> <comma> <e>
<Multi_key> <comma> <E>
Consistency. <Multi_key> <comma> [:letter:] is for letter with cedilla, <Multi_key> <semicolon> [:letter:] is for letter with ogolek

<Multi_key> <C> <slash>
<Multi_key> <slash> <C>
Unintuitive. ¢ is visually a vertical bar through a lowercase c, not a slash through an uppercase C. ₡ has no alternatives, whilst ¢ can be typed as <Multi_key> <bar> <c>.

<Multi_key> <d> <minus>
đ can be input through <Multi_key> <minus> <d>. <Multi_key> <d> <minus> is used for ₫.

<Multi_key> <equal> <L>
<Multi_key> <L> <equal>
Unintuitive. ₤ has two dashes, £ one; therefore L + = > ₤, and L + - = £.

<Multi_key> <exclam> <s>
<Multi_key> <exclam> <S>
Consistency. <Multi_key> <exclam> [:letter:] is used for letter with dot below. § can be input using <Multi_key> <o> <s>.

<Multi_key> <period> <period>
Might need an alternative for ˙, but … (upstream) has no alternative either.

<Multi_key> <underscore> <a>
<Multi_key> <underscore> <A>
<Multi_key> <underscore> <o>
<Multi_key> <underscore> <O>
Consistency. <Multi_key> <underscore> [:vowel:] gives vowel with macron for ȳ ū ī ē too.

<Multi_key> <minus> <d>
<Multi_key> <minus> <D>
<Multi_key> <o> <e>
<Multi_key> <O> <E>
Redundant. In upstream as is.

With the above patch all obvious conflicts should be resolved, but there might be more conflicts of sequences that use three keys in the legacy file, and more than three in the X.org compose sequences file, as I noted in comment 29. A script that can check for those conflicts as well might be good.

Also, with the patch suggested above the ˙ (dot above) no longer has a compose sequence. The rest have alternatives upstream.

"me too" for ellipsis on <compose>,<period>,<period>

In case you really want a combo for dot above: what about compose,*,*?

Does this als fix this bug http://bugzilla.gnome.org/show_bug.cgi?id=565912 ?

The macron (a horizontal bar over a vowel) has been implemented for eEiIuU but not for aAoO. Please implement the following:

<Multi_key> <O> <minus> capital O with macron
<Multi_key> <minus> <O> capital O with macron
<Multi_key> <o> <minus> small O with macron
<Multi_key> <minus> <o> small O with macron
<Multi_key> <A> <minus> capital A with macron
<Multi_key> <minus> <A> capital A with macron
<Multi_key> <a> <minus> small A with macron
<Multi_key> <minus> <a> small A with macron

At the moment the combinations above are mapped to a tilde in stead of a macron. A tilde can also be used, like for eEiIuU, with tilde and compose key.

Implementing this change will make combination of macro and tilde consistent for all vowels. The use of macron is especially important for writing Romaji (Japanese in latin/roman characters).

Can this be implemented in proposed patch?

Implementing the proposal above regarding consistent macrons, should reimplement the following in order to offer masculine and feminine ordinal indicator. Proposal is to do this in a similar way for other superscripts, also to maintain consistency.

<Multi_key> <S> <A> feminine ordinal indicator
<Multi_key> <S> <a> feminine ordinal indicator
<Multi_key> <s> <A> feminine ordinal indicator
<Multi_key> <s> <a> feminine ordinal indicator
<Multi_key> <S> <O> masculine ordinal indicator
<Multi_key> <S> <o> masculine ordinal indicator
<Multi_key> <s> <O> masculine ordinal indicator
<Multi_key> <s> <o> masculine ordinal indicator

Note that only the s or S can be used for this superscript symbol, since the tilde, minus, underscore and circumflex are already used in full consistent ranges with other vowels than aAoO.

@pander --

See Comment #33 and #34 above regarding macron compose sequences.  

I'm a newbe here but willing to do serious testing and make some valuable contributions because I use the compose key a lot.

So in the idea above is to have both minus and underscore for adding a macron to vowels and consonants? Would it not be better to use the minus for macron and stroke for glyphs like ūđĐḠꝈ and underscore for glyphs like ẔṯṟḴ?

Not that I personally use them, but how will masculine and feminine ordinal
indicator be composed? Like I proposed with an s or S like the superscript 1, 2, 3?

Too bad this compose table has to be compiled in order to really test it out. In order to make a better contributions and really work with the latest version you all have created, I should use Jeroen Hoek's patch from 2009-05-18 18:16 UTC on gtk-compose-lookaside.txt from December 3 2008 from svn and compose-parse.py and gtkimcontextsimpleseqs.h from that same date from svn in an apt-get source of gtk+2.0-2.16.1? Will that bring my Ubuntu 9.04 compose functionality up to date to latest and greatest?

What do you all think of generating (HTML) documentation for the end users, like the one here: https://help.ubuntu.com/community/GtkComposeTable It would be better if that page would use generated documentation supplied with each release.

With up to date generated documentation, users satisfaction will increase because a complete overview will give insight into the rules behind the intuitive compose sequences.

@pander: You can rather easily compile the latest gtk+ in a separate directory, and select on demand to run any gtk+ program using this new gtk+ library. For more see http://simos.info/blog/archives/15 (feel free to ask specific questions at the blog comments). You can make small changes in the gtk+ code, recompile (about 20s) and test.

I would like to refresh the overall issue with compose sequences and GTK+.
1. GTK+ started using compose sequence in about 2001, and these compose sequences came from the X.Org sources.
2. Since then, the gtk+ compose sequences stayed mostly as is, while in X.Org the compose sequences increased dramatically in number, and non-standard sequences where removed. We got to a state where gtk+ had 800 compose sequences and X.Org over 5000 of them.
3. Last year, gtk+ was updated and got in sync with X.Org, both at about 5000 compose sequences. New users happy to type so many new characters.
4. During the update, several legacy compose sequences found in GTK+ were silently removed (there was no provision for the issue 'can we get a list of compose sequences that gtk+ had, but X.Org no longer has?'). The reason for this report is that users who got used to the legacy gtk+ compose sequences, realised that some things were not working. The purpose of gtk-compose-lookaside.txt was to reintroduce the lost legacy gtk+ compose sequences.
5. The new gtk+ that was released with gtk-compose-lookaside.txt had a problem; some compose sequences that used to exist for the last year's gtk+ release do not work anymore. There are conflicting compose sequences.
6. The source of the problem is that several legacy gtk+ compose sequences do not play well with the spirit of the compose sequence mechanism. For example, it makes sense to use sequences starting with 'Compose + (' for ①②③④⑤⑥⑪⑫⑬⑭ⒶⒷⒸⒹ (Unicode characters in circle). However, if a legacy compose sequence wants to use 'Compose + ( + a for ă, it would mess up with the general rule for ①②③④⑤⑥⑪⑫⑬⑭ⒶⒷⒸⒹ because we would not be able to type ⓐ.
7. In other words, the issue is that it requires care when defining the first character after the Compose key (as in Compose + ( ).
8. We regard as upstream source the compose sequence list found at X.Org. New additions to compose sequences can take place at bugs.freedesktop.org, and it would actually be good to migrate as many of the legacy gtk+ compose sequences to X.Org. The maintainer is quite responsive for these issues.
9. The correction (listed above in the comments) to the lookaside table in gtk+ is something that needs to happen soon in order to fix the most important issues.
10. It might require to change some of our habits with compose sequences. We will need to give up some compose sequences we are used to, in order to stay better in sync with X.Org.

@Simos:

Is the patch I attached in comment 34* sufficient for correcting the lookaside table?

* ㉞?

(In reply to comment #43)
> @Simos:
> 
> Is the patch I attached in comment 34* sufficient for correcting the lookaside
> table?
> 
> * ㉞?
> 

The patch looks good. The issue stands on me to produce the updated C table,
http://git.gnome.org/cgit/gtk+/tree/gtk/gtkimcontextsimpleseqs.h
using the latest version of the script at http://github.com/simos/compose-parse/
Sorry for the delays. 

@Simos or other devs:

I'm ignorant of the history here -- is there any solid, unshakable reason for why the compose tables must be compiled into GTK, as opposed to being editable text files as they are for X?  Using text files would allow folks to customize to their hearts' content, and even circulate different versions (perhaps sharing older-style GTK compose sequences, for instance).  

For that matter, I'm honestly confused as to why there is no option to just use the standard X compose table files as-is...?  As GTK moves closer to using the X defaults, there seems less and less need to keep things separate.

As some of you already suggested, would it be an idea to start a new issue with a roadmap on which steps to take in order to offload all the compose combinations to upstream xorg? Then, step by step, work towards this.

This would allow for the same rich set of combinations for all window managers and applications under xorg. Also it would allow expanding or overriding these settings without recompilation.

Eiríkr, pander: Such a discussion is more suitable for the mailing list, http://mail.gnome.org/mailman/listinfo/gtk-i18n-list 
It is good etiquette to keep the discussion here focused on the bug report itself.

Simos:

Will the updated compose table be included in the upcoming Gnome 2.28? I fear that another six months of conflicting legacy compose sequences might result in users getting used to sequences we have tagged for removal in this bug report.

http://git.gnome.org/browse/gtk+/tree/gtk/gtkimcontextsimpleseqs.h shows the correct characters for <a>/<o> <minus> and <minus> <a>/<o> etc. now, does this mean this bug will be fixed in Gnome 2.30?

Related: bug #601234

I have applied the patch in comment #34 now, and regenerated the tables.