UIM 1.2.0 has broken the Compose key operation, which used to work flawlessly in 1.1.1 and earlier. With 1.2.x, only very few combinations work (such as Compose + a + e (æ) or Compose + / + o (ø), but NOT Compose + o + /), and the vast majority has no effect. They're not regarded as invalid (it doesn't beep), just eaten silently, and actual invalid combos (such as C + h + y) result in the last character (here "y") input being inserted instead of a beep. This is a showstopper for anyone relying on Compose operation (like me, I am Polish but live in Denmark, and use Compose to do 100% of my Danish writing); setting the severity to critical because not many people know or use Compose, but otherwise it's a blocker. The version of UIM is 1.2.0 / 1.2.1, official releases compiled from source on Ubuntu 6.06 Dapper, with the following config: Anthy : no Canna : no Mana : no PRIME : no m17n-lib : no SCIM : no Gtk+ : yes Gnome Applet : yes Qt : no Qt immodule : no FEP : no Emacs : yes XIM : yes Pref : yes DICT : no EB : yes libedit : no Default toolkit : gtk prefix=/usr/ (it was built into a .deb with checkinstall) 1.1.1 from official sources compiled with the exact same config works like a charm. It occurs at least for GTK+, can't test it for Qt as I didn't build it. As a sidenote, the very same thing occurs when you select XIM as input method from GTK+'s context menu without an input method actually running.
Thanks for the report. From uim 1.2.0, our GTK+ and Qt input modules use X11's compose sequence table in backend compose input instead of gtk+ internal one, as requested in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377808. The reporter said GTK+'s internal table is not sufficient for user of traditional X11. If you use da_DK.UTF-8 locale, $prefix/share/X11/locale/en_US.UTF-8/Compose is used as a compose table. And it doesn't seems to have "<Multi_key> <o> <slash>" sequence as ø letter. That the problem. One way to solve the problem is copy $prefix/share/X11/locale/en_US.UTF-8/Compose as $HOME/.XCompose, and add your required compose sequences as follows. <Multi_key> <o> <slash> : "ø" U00F8 Could you tell me which sequences have no effent (you said the vast majority) with uim-1.2.1? Cheers, -- Etsushi Kato
*** Bug 8117 has been marked as a duplicate of this bug. ***
See message in http://lists.freedesktop.org/archives/uim/2006-September/001532.html and http://lists.freedesktop.org/archives/uim/2006-September/001533.html. Maybe we should merge compose table of gtkimcontextsimple and xorg's UTF-8 compose file.
Okay, it seems that I was just a particularly good target, having used GTK+ Danish sequences. Below is the content of my ~/.XCompose, until the two are merged. This is not by any means complete, just the sequences I noticed the lack of immediately: <Multi_key> <O> <slash> : "Ø" U00D8 # LATIN CAPITAL LETTER O WITH STROKE <Multi_key> <O> <KP_Divide> : "Ø" U00D8 # LATIN CAPITAL LETTER O WITH STROKE <Multi_key> <o> <slash> : "ø" U00F8 # LATIN SMALL LETTER O WITH STROKE <Multi_key> <o> <KP_Divide> : "ø" U00F8 # LATIN SMALL LETTER O WITH STROKE <Multi_key> <A> <A> : "Å" U00C5 # LATIN CAPITAL LETTER A WITH RING ABOVE <Multi_key> <A> <*> : "Å" U00C5 # LATIN CAPITAL LETTER A WITH RING ABOVE <Multi_key> <*> <A> : "Å" U00C5 # LATIN CAPITAL LETTER A WITH RING ABOVE <Multi_key> <a> <a> : "å" U00E5 # LATIN SMALL LETTER A WITH RING ABOVE <Multi_key> <a> <*> : "å" U00E5 # LATIN SMALL LETTER A WITH RING ABOVE <Multi_key> <*> <a> : "å" U00E5 # LATIN SMALL LETTER A WITH RING ABOVE <Multi_key> <e> <equal> : "€" EuroSign # EURO SIGN <Multi_key> <equal> <e> : "€" EuroSign # EURO SIGN <Multi_key> <T> <M> : "™" U2122 # TRADE MARK SIGN However, there's another bug. ~/.XCompose *replaces*, and not augments normal systemwide compose tables, so if you add ~/.XCompose, you lose all previously defined sequences. As I can't find any way to say "include file", I needed to copy verbatim the whole $prefix/share/X11/locale/en_US.UTF-8/Compose and paste it into my ~/.XCompose. If anyone can confirm that behaviour, it needs reporting in X.org.
Thanks for the list of sequences. Since I haven't started to investigate the diff between X11's Compose and GTK+ yet, it will help. > However, there's another bug. ~/.XCompose *replaces*, and not augments normal > systemwide compose tables, so if you add ~/.XCompose, you lose all previously > defined sequences. As I can't find any way to say "include file", I needed to > copy verbatim the whole $prefix/share/X11/locale/en_US.UTF-8/Compose and paste > it into my ~/.XCompose. If anyone can confirm that behaviour, it needs reporting in X.org. X.org's Compose surely supports "include file" system. Please try to add following line in ~/.XCompose that contains only your specific sequences. include "/usr/share/X11/locale/en_US.UTF-8/Compose"
hooray for finding old bugs on google, just wanted to mention you can use this to include the default compose map easily: include "%L"
Here is a patch which replaces the compose table in Gtk+ with the table taken from libX11-1.1.1 (excluding characters above U+FFFF which are not supported by UIM). It includes a script to regenerate it. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/gtk+2-compose-table.patch.bz2 Although the new table doesn't include e.g. [o/ → ø], leaving only [/o → ø], it's richer in other areas, e.g. [<" → “], [>" → ”], [," → „]. Some diacritics have been disunified: , = cedilla, ; = ogonek. The diacritic is always before the base letter, which leaves room for letter keys to denote some diacritics, e.g. o = ring above. I propose to let Gtk+ use the same table as X11 by default, to avoid user confusion. Further improvements should be done in both sources.
(In reply to comment #7) > I propose to let Gtk+ use the same table as X11 by default, to avoid user > confusion. Further improvements should be done in both sources. Thanks for letting us know about the patch. I think you should add your comment on GTK+'s bugzilla (http://bugzilla.gnome.org/show_bug.cgi?id=88639).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.