16

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

Improve this question
1
  • I had this problem with ctrl-; (ctrl-semicolon), and the accepted answer also worked for me.
    – Jim Hunziker
    Commented Jul 10, 2022 at 12:18

1 Answer 1

Reset to default
19

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 []"
Improve this answer
5
  • 2
    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.
    – Steve
    Commented Nov 14, 2021 at 6:30
  • 3
    Worked for me.. what an annoying "feature"
    – demented hedgehog
    Commented Mar 20, 2022 at 23:00
  • 1
    you don't need "@as []", you can just say [] and it works fine too. I'm using Fedora 36.
    – xdavidliu
    Commented Sep 10, 2022 at 1:04
  • @xdavidliu what does @as do?
    – Rubem Pacelli
    Commented Nov 11, 2023 at 19:29
  • 1
    @RubemPacelli: @as indicates that the value is of "array of strings" type (GSettings and dconf are strongly-typed, but usually guess the type from the value itself – but an empty [] only tells them that it's an array-of-something). It's apparently not necessary for GSettings as the type is already specified in schema, though I think it would still be necessary for dconf write.
    – grawity_u1686
    Commented Nov 11, 2023 at 19:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .