libx11-data: compose ellipsis problem

[Alex Mauer]

According to the compose file /usr/share/X11/locale/en_US.UTF-8, pressing Compose, period, period, should give an ellipsis ("…"):
<Multi_key> <period> <period> : "…" ellipsis # HORIZONTAL ELLIPSIS

However, on my system it instead gives a "dot above" (˙, unicode 0x02D9) which should be produced by a totally different sequence involving deadkeys which I don't have.

[Bryce Harrington (bryce)]

Hi hawke,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log (and maybe Xorg.0.log.old) file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Alex Mauer (hawke)]

I don't think lspci or xorg.log are appropriate for this bug. Certainly xorg has nothing relevant to xkb, besides
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "us"

[Bryce Harrington (bryce)]

Alex, you misfiled this bug against libx11 instead of the correct package, xkeyboard-config.

[Matt Wilson (matt-culturethree)]

I'm seeing this too, after upgrading 8.10 to 9.04. It happens in Pidgin, Firefox and gnome-terminal, but NOT for some reason in xterm or urxvt. My locale is en_NZ.UTF-8. I'll attach the requested logs.

[Matt Wilson (matt-culturethree)]

I can confim that this still exists in Karmic Koala.

[Vianney le Clément (vleclement)]

I have the same problem in karmic.

However, the bug doesn't happen when one selects "X Input Method" as input method (you can change it by right-clicking on a textbox and choose from the "Input Methods" submenu). By default, karmic (and probably jaunty too) uses IBus. As a workaround, you can add "export GTK_IM_MODULE=xim" to /etc/environment.

The drawback is that I face another bug using XIM in gedit: whenever I use a hotkey (for example Alt+... to access menus), the Compose key completely stops working afterwards. To make it work again, I have to reselect XIM from the input methods menu.

[Vianney le Clément (vleclement)]

Two people have confirmed this bug. Changing status in the hope it will get some visibility.

[AlexYeCu (alexyecu)]

That`s not only Ubuntu`s bug. I use Fedora, so, I`ve noticed this bug in Fedora10. It has came with some of last updates of x11-libs. And this bug is still presented in Fedora12. May be this info will help you to find out the buggy version of libs/data. Or to developers of a buggy package.

[gillux (gillou-ray)]

I'm not a ubuntu user too. However I figured out that the default input method in GTK applications can be changed by the GTK_IM_MODULE environment variable. I don't know how its default value is chosen, though. And that may be the point. Available values for this variable should be listed in the first column of /etc/gtk-2.0/gtk.immodules. The one Alex wants is "xim" which stands for "X Input Method". So a workaround is to set GTK_IM_MODULE="xim" in some startup script and you should see it selected by default in the "Input Methods" submenu of the text fields contextual menus. I've also heard of a QT_IM_MODULE similar variable but havn't tested it.

[Vianney le Clément (vleclement)]

Note that this problem seems to be solved in lucid.

[Simos Xenitellis  (simosx)]

I also verify that the issue is fixed in Ubuntu 10.04 (without having to resort to the activation of 'xim').
If you press Compose + . + . you get …

Closing this report, thanks for reporting.

[Adrián Chaves (gallaecio)]

I’m suffering this issue in Kubuntu 13.04 with KDE applications; has it ever been fixed for those? (Writting this message I’ve just found out that it works on Firefox… ← That’s the proof)