General Computing
linux keyboard-shortcuts xorg xkb xinput
Updated Fri, 03 Jun 2022 01:03:33 GMT

What is my X11 doing with Ctrl-Period and how can I disable it?

How do I disable whatever X-window-system-wide setting is intercepting Ctrl-Period for some kind of special input popup?

More detail: I'm trying to bind an emacs command to Ctrl-Period (C-.), which worked fine on a previous system. On this new computer there seems to be something going on at the X level (xinput? xkb?) that's intercepting the keystroke so that emacs (or most other applications) simply aren't seeing it.

Instead, when I press Period while holding Ctrl, a small underlined "e" appears, either in-line when I'm in a graphical window, or as a popup on a terminal or emacs window (see images below). If I type further characters, they show up after the underlined "e", also underlined. The later characters can be backspaced, but the "e" cannot, and remains until I press either Enter, Esc, or a second Ctrl-Period. In the latter two cases (a second C-. or Esc) all the underlined characters disappear with no other effect, while in the former case (Enter) they disappear but immediately send the following keystrokes.

This is clearly happening at the window-system level because if I press C-. in one application and then move my cursor to another to type, the popup jumps between windows to whichever has focus (with sometimes odd side effects).

Finally, some applications do see the keystroke: if I add an key event listener to a blank webpage in Chrome, as long as I don't have an input element focused, the key event is emitted exactly as I'd expect. But if I have an input element focused, then weird "unidentified" keys are emitted while the underlined "e" is showing.

Result of ctrl-period (followed by "123") in browser location bar: 1

Result of ctrl-period (followed by "456") in terminal, emacs is similar: 2


This looks like the "preedit area" of some X Input Method provider, allowing you to compose a character before it gets sent to the actual input of the application.

(For example, a preedit dialog is used when composing Japanese text in fcitx or IBus, or when entering Unicode codepoints in GTK's Ctrl+Shift+U. Usually it is the application toolkit such as GTK or Xlib which communicates with the IM module, telling it about text fields being in focus, etc.)

In this case it's likely used for emoji input by name, guessing from the 'e' prefix and the keyboard shortcut. I'm guessing that this specific "input method" is part of the IBus input framework, where emoji input is built-in and the default shortcut is indeed Ctrl+period. (Normally it should show a graphical chooser but in some cases only basic IM support is available and all you get is the preedit field.)

However, check the XMODIFIERS and GTK_IM_MODULE environment variables for additional clues. (IBus is not the only XIM server out there.)

IBus has the keyboard shortcut customizable through ibus-setup, or via GSettings:

gsettings get org.freedesktop.ibus.panel.emoji hotkey

This shows that the default value is ['<Control>period']. To set it to an empty list, use:

gsettings set org.freedesktop.ibus.panel.emoji hotkey "@as []"

Comments (2)

  • +0 – Thank you very much, that's exactly what was happening. XMODIFIERS showed @im=ibus, GTK_IM_MODULE was ibus, and the emoji hotkey setting was ['<Control>period'], which I was able to disable with your command. I have no idea how the emoji input is supposed to work (typing "smily" or anything else in there doesn't seem to do much good), so I'm glad I can turn it off but still keep Ctrl-Shift-U, which is actually useful. — Nov 14, 2021 at 06:30  
  • +0 – Worked for me.. what an annoying "feature" — Mar 20, 2022 at 23:00