GTK: Spanish dead key input breaks input buffer

[Diego-0110]

I've tried to write with an spanish keyboard layout, and every time I pressed a dead key (like: ´ or ¨) the input buffer stops working.

The same thing happends using the 'Compose Key' option of the keyboard configuration on Ubuntu.

Steps to reproduce:

1. Change your keyboard layout to other with dead keys, like Spanish or French.
2. Write something with a dead key, like á or ä.
3. Try to continue writing.

Bug:

• After pressing a dead key, the characters introduced will be overwritten one after another and special keys like Enter or Backspace won't work as expected.
• The bug only affects the tab in which you've pressed the dead key.

Ubuntu 24.04.1 LTS

❯ ghostty --version
Ghostty 1.0.0

Version
  - version: 1.0.0
  - channel: stable
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.gtk
  - font engine: font.main.Backend.fontconfig_freetype
  - renderer   : renderer.OpenGL
  - libxev     : main.Backend.io_uring
  - GTK version:
    build      : 4.14.2
    runtime    : 4.14.2
  - libadwaita : enabled
    build      : 1.5.0
    runtime    : 1.5.0

[sracha4355]

May I try working on this?

[jcollie]

May I try working on this?

Please do! Just read https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md first.

[beppler]

This happens on Brazilian Portuguese keyboard layouts too.

[llynch]

Edit 2025-01-06

running ghostty on ubuntu 24.04.1 LTS with ibus version 1.5.29 and gtk version 4.14.2 fixes the accent issue for me.
GTK_IM_MODULE=simple

found this tip here: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/2064025

---

I know this is not a valid fix, but at least with this hitting <esc> exit the composing mode and is a better workaround than exiting ghostty loosing your current work session.

if (std.math.cast(u21, keyval_unicode)) |cp| {
        if (cp == 0x1B) self.im_composing = false;
    }

0x1B == Escape key

So far my investigation seems to show that preedit-end is never called. I this callback from GTK should be call when a dead key sequece is completed and therefore stop the composing mode, but it does not seems to be ever called for some reasions.

UPDATE 2025-01-05:
I am also running on GTK 4.14.2. I am starting to thinks it is a bug with GTK, the preedit-end is never call making the states for this to be incosistent.
Focussing out of the ghostty windows calls the preedit-end, but it will never do if we keep the focus on and continue typing.

[beppler]

I think this can be related to the following discussions:
#2577 (from #2576)
#3164

[santimc]

running ghostty on ubuntu 24.04.1 LTS with ibus version 1.5.29 and gtk version 4.14.2 fixes the accent issue for me.
GTK_IM_MODULE=simple

I'm also running ubuntu 24.04.1 LTS with ibus version 1.5.29, gtk version 4.14.2 and GTK_IM_MODULE=simple
Sadly, I just rebuilt ghostty just in case and the workaround doesn't seem to solve it for me

Version
  - version: 1.0.2-main+a2445359
  - channel: tip
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.gtk
  - font engine: font.main.Backend.fontconfig_freetype
  - renderer   : renderer.OpenGL
  - libxev     : main.Backend.io_uring
  - desktop env: other
  - GTK version:
    build      : 4.14.2
    runtime    : 4.14.2
  - libadwaita : enabled
    build      : 1.5.0
    runtime    : 1.5.0
  - libX11     : enabled
  - libwayland : enabled

[Diego-0110]

I'm also running ubuntu 24.04.1 LTS with ibus version 1.5.29, gtk version 4.14.2 and GTK_IM_MODULE=simple Sadly, I just rebuilt ghostty just in case and the workaround doesn't seem to solve it for me

I've also tried to use GTK_IM_MODULE=simple (with the same version of Ubuntu, ibus and GTK and with Ghostty 1.0.0) and solves partially the problem. Run env GTK_IM_MODULE=simple ghostty from another terminal or change the Exec param in the .desktop file of Ghostty.

The thing with GTK_IM_MODULE=simple is that disables the emoji and unicode modules from ibus.

[isama92]

I also had this problem with Ubuntu 24.04, yesterday I upgraded it to 24.10 and now it's working properly.

[bjce]

I have the same problem on qwertz keyboard (Switzerland) on Linux Mint 22 with Cinnamon desktop environment (and had opened a discussion there #5240 before seeing this issue). I'll be glad to give any additional information if needed. Many thanks for your support

[mitchellh]

What desktop environment are you all using for this? I'm on Gnome and set the keyboard layout to Spanish and I'm able to type accented characters fine. I absolutely believe this is happening to people just trying to figure out how to reproduce it in order to debug further...

[JulienMasgonty]

What desktop environment are you all using for this? I'm on Gnome and set the keyboard layout to Spanish and I'm able to type accented characters fine. I absolutely believe this is happening to people just trying to figure out how to reproduce it in order to debug further...

Using Ubuntu 24.04 here, had the same issue, using both gnome and i3 (french azerty keyboard)

Can confirm that as mentioned by @isama92, upgrading to ubuntu 24.10 fixes it (on both gnome and i3)

Could it be in any way related to ibus/ibus#2637 ?

Upgrading from ubuntu 24.04 to ubuntu 24.10 also happens to upgrade ibus from 1.5.29 to 1.5.30

[mitchellh]

If upgrading fixes it, this is pointing towards an upstream issue. I just committed a number of input method improvements on tip too if anyone wants to give that a shot. If we can't get a reproduction on this though I will ultimately close it (and we can move back to discussions).

[emogenet]

What desktop environment are you all using for this?

On ubuntu 24.04, it seems to happen pretty much independent of the desktop "environment"

I've reproduced it on:

• i3wm
• cinnamon
• the standard ubuntu windows manager whose name I forget

Also, you don't need a spanish keyboard to reproduce this, a regular US keyboard exhibits the same problem when you use the compose key.

If you want to try it, here's how to assign the compose key to the "right alt" key on your US keyboard:

setxkbmap -option compose:rctrl_ralt

after that, typing: "right_alt" followed by: "backquote" followed by: "a"

should produce : "à"

It does in e.g. gnome terminal

ghostty goes into an infinite compose mode

it may be a gnome bug, but given that none of the other terminal emulators I've tried seem to have the problem, it'd be swell if ghostty could implement the same logic the other terms do ... upstreaming will take a long time and ubuntu 24.04 is an LTS

[santimc]

After I upgraded from 1.0.2-main+a2445359 to 1.0.2-main+ddf7173a (the latest commit), the issue it's almost resolved. When I type a key that composes ghostty doesn't hang anymore, but the cursor converts to a box with the compose key inside. After switching focus to another program and coming back the cursor goes back to normal.
After a bisect the commit that seems to semi-resolve the issue is 52936b9

Also in any version when I press this kind of keys this ibus warning is raised
IBUS-WARNING **: : ibus_input_context_post_process_key_event: Type 'h' is not supported.

[emogenet]

Just downloaded the latest ghostty source code from github and compiled it:

$ cd ghostty/; git log | grep commit | head -1
commit ddf7173ae92b4992c4506b6df4681c0687cc29c3

Behavior is different in that you don't get stuck in compose mode anymore, but the problem persists: the compose key does not work as it should

$ ~/sw/ghostty-20250125/bin/ghostty --version
Ghostty 1.0.2-main+ddf7173a

Version
  - version: 1.0.2-main+ddf7173a
  - channel: tip
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.gtk
  - font engine: font.main.Backend.fontconfig_freetype
  - renderer   : renderer.OpenGL
  - libxev     : main.Backend.io_uring
  - desktop env: other
  - GTK version:
    build      : 4.14.2
    runtime    : 4.14.2
  - libadwaita : enabled
    build      : 1.5.0
    runtime    : 1.5.0
  - libX11     : enabled
  - libwayland : enabled

[luizpbraga]

Dead keys not working on NixOS with i3wm (US keyboard, Ghostty 1.0.2-main+ddf7173a) :/

[mitchellh]

Dead keys not working on NixOS with i3wm (US keyboard, Ghostty 1.0.2-main+ddf7173a) :/

Since you’re on NixOS can you share your configs? I should be able to run your config and reproduce.

I don’t need any more confirmations from people I need a reproduction or actionable information to fix this.

[sto]

Just FYI, I'm using the same version on Ubuntu 24.04.1 (Ghostty 1.0.2-main+ddf7173a) and compose works, but the cursor keeps the dead key character; i. e. if I type anything with an accent, like ú it works but the cursor block keeps the ´ from that moment on until the window looses the focus or I type a different compose character (i.e. ¨)

[Diego-0110]

I've tried the latest version of Ghostty (1.0.2-main+ddf7173a) in two virtual machines: one with Ubuntu 24.04 and the other with Ubuntu 24.10. The two machines use GNOME as desktop environment and ibus as input method. I also tried using X11 and Wayland.

Ubuntu 24.04

• ibus version: 1.5.29.rc2

Ghostty with X11

• Spanish layout: dead keys don't break input buffer, but leaves the character inside the cursor. This character disappears after changing from one tab to another.

• Compose key (Settings>Keyboard>Compose Key): the first time you use it works, but leaves the character inside the cursor. Then after that, the character also appears at the start. This behaviour restarts after changing from one tab to another.

• Unicode input (Ctrl+Shift+u): works well, but leaves the characters from the keyboard shortcut.

• Emoji input (Super+.): works well, but leaves the characters from the keyboard shortcut.

Ghostty with Wayland

• Spanish layout: dead keys work well.
• Compose key: works well.
• Unicode input: works well.
• Emoji input: works well.
• Minor bug: if you use the Unicode input method after using a dead key, the cursor has the dead key character inside until you press another key.

Ubuntu 24.10

• ibus version: 1.5.30

Ghostty with X11

• Spanish layout: works well.
• Compose key: works well.
• Unicode input: same problem as Ubuntu 24.04 with X11.
• Emoji input: same problem as Ubunutu 24.04 with X11.

Ghostty with Wayland

• Spanish layout: dead keys work well.
• Compose key: works well.
• Unicode input: works well.
• Emoji input: works well.
• Same minor bug as Ubuntu 24.04 with Wayland.

[mitchellh]

Excellent @Diego-0110, thank you very much. This gives me some very specific configurations to look into.

[emogenet]

I need a reproduction

Below is a link to a qemu/kvm raw VM image that contains:

• a fresh install of ubuntu 24.04.1 LTS
• tweaked to start X11 and not wayland
• a minimal dev env
• zig 0.13 in the path of the shell
• the latest ghostty source tree already compiled (in release mode though)
• the compose key configured to be mapped to to right-ALT
• login is: mitch, passwd is: mitch

Run it with on a x86-64 linux host with something like:

/usr/bin/kvm                          \
  -m 4G                               \
  -cpu host                           \
  -hda ub2404.raw                     \
  -smp 2,sockets=1,cores=2,maxcpus=2  \

Once it's booted, log in and pop open a gnome terminal

try to enter in gnome-terminal:

right-ALT = e

should produce: €

and then:

cd ~/Desktop/ghostty
./zig-out/bin/ghostty

and try to do the same in the ghostty window

On this setup, it seems to manage to actually produce the € char, but ghostty is still left in a weird state, the cursor is weird.

My own setup on my laptop is quasi-identical to this, with the exception that I use i3wm instead of the standard ubuntu windows manager. And on my setup ghostty does not even produce the desired char.

The VM image is a tad large (17G), apologies:

http://mgix.me/files/ub2404.raw

[luizpbraga]

Dead keys not working on NixOS with i3wm (US keyboard, Ghostty 1.0.2-main+ddf7173a) :/

Since you’re on NixOS can you share your configs? I should be able to run your config and reproduce.

I don’t need any more confirmations from people I need a reproduction or actionable information to fix this.

Here's the relevant configuration from my NixOS setup:

i3 Config

# Keyboard layout settings
exec --no-startup-id setxkbmap -layout us -variant intl

configuration.nix

{
  services.xserver = {
    enable = true;
    xkb = {
      layout = "us";
      variant = "intl";
    };
  };
  
  console.keyMap = "us";

  # Other system info
  time.timeZone = "America/Sao_Paulo";
  i18n.defaultLocale = "en_US.UTF-8";
  i18n.extraLocaleSettings = {
    LC_CTYPE = "pt_BR.UTF-8"; # To allow special characters like ç
  };

  services.xserver.windowManager.i3.enable = true;
  services.xserver.windowManager.i3.package = pkgs.i3-gaps;
}

System Information

nixos-version:

24.11.710315.b681065d0919 (Vicuna)`

nix-info:

system: "x86_64-linux", multi-user?: yes, version: nix-env (Nix) 2.24.10, channels(root): "nixos-24.11, unstable", channels(luizpbraga): "", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

uname -a:

Linux nixos 6.6.63 #1-NixOS SMP PREEMPT_DYNAMIC Fri Nov 22 14:38:37 UTC 2024 x86_64 GNU/Linux

ghostty --version

Ghostty 1.0.2-main+ddf7173a
Version
  - version: 1.0.2-main+ddf7173a
  - channel: tip
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.gtk
  - font engine: font.main.Backend.fontconfig_freetype
  - renderer   : renderer.OpenGL
  - libxev     : main.Backend.io_uring
  - desktop env: other
  - GTK version:
    build      : 4.16.3
    runtime    : 4.16.3
  - libadwaita : enabled
    build      : 1.6.2
    runtime    : 1.6.2
  - libX11     : enabled
  - libwayland : enabled

Let me know if you need any more details or specific logs to debug this further.

[mitchellh]

Thanks @luizpbraga, I was able to spin up a version using your relevant config but likely with a different nixpkgs pin and I'm unable to reproduce the issue. Accented character input works fine. i.e. typing ' and a works. No composition state hanging. Let me know if I'm doing something wrong...

[mitchellh]

@Diego-0110 PR #5310 should address the minor ibus issues you noted. I was able to reproduce them thanks to your notes. It doesn't address the ibus .29 dead key issue which I haven't yet reproduced.

[Diego-0110]

Now I've tried Ghostty version 1.0.2-main+eb21a58a.

❌: previous bug not solve.
🟨: previous bug solved, but others bugs found.
✅: works as expected.

Ubuntu 24.04

• ibus: 1.5.29.rc2

X11

• Spanish layout: ❌.
• Compose key: ❌.
• Unicode input: 🟨. Other bugs:
  • Ghost character: if you use the Unicode input method after using a dead key, the cursor has the dead key character inside until you press another key.

• Setting a different shortcut with ibus-setup: I tried to set Super+u as an additional shortcut for the Unicode input and when I used it the characters are not process by ibus. In the screenshot, the result should be uaa to get ª.

• Emoji input: 🟨. Other bugs:
  • Sometimes don't work: I couldn't find a way to replicate (maybe try multiple times), but sometimes the input is ignored and the characters are not processed by ibus (same as with Unicode input and the custom shortcut).

Wayland

• Spanish layout: ✅.
• Compose key: ✅.
• Unicode input: ✅.
• Emoji input: ✅.
• Minor bug: ghost character when using unicode or emoji input after a dead key.

Ubuntu 24.10

• ibus: 1.5.30

X11

• Spanish layout: ✅.
• Compose key: ✅.
• Unicode input: 🟨. Same bugs as Ubuntu 24.04 with X11.
  • In this case, the bug with the custom shortcut sometimes doesn't occur.
• Emoji input: 🟨. Same bugs as Ubuntu 24.04 with X11.

Wayland

• Spanish layout: ✅.
• Compose key: ✅.
• Unicode input: ✅.
• Emoji input: ✅.
• Same minor bug as Ubuntu 24.04 with Wayland.

[mitchellh]

@Diego-0110 Thanks, note on this:

Ghost character: if you use the Unicode input method after using a dead key, the cursor has the dead key character inside until you press another key.

This appears to be a GTK4 bug. I've inserted logging and when calling the GTK function gtk_im_context_get_preedit_string to retrieve the preedit string, GTK itself is giving us the text with the previous dead key character.

I've confirmed that when going from deadkey to unicode input the following events are fired:

1. preedit start (deadkey)
2. preedit change (deadkey value i.e. ')
3. preedit end (pressed ctrl+shift+u to enter Unicode)
4. preedit start (same as above)
5. preddit change (GTK reports preedit value is u')

I don't believe this is our issue, since we don't control the preedit text. Ghostty is properly clearing it on the start/end events but GTK immediately fires a change event that has the bad text.

[Diego-0110]

@mitchellh It seems like it. I also found the bug in other applications like Chrome or the Gnome Terminal. So maybe it's unrelated to the dead key character bug.

[mitchellh]

This issue is fixed by #5324.

It appears the issue is that ibus 1.5.29 doesn't clear the preedit state when text is committed. ibus 1.5.30 does and every version of fcitx I've ever tested does as well. This seems to be the ibus bug. I've worked around this in #5324 by assuming preedit should clear when text is committed. I've never seen an input method require the alternate so I think this is safe to do.

[tomaspinho]

Just cross-linking my experience here: #5324 (comment)

TL;DR: these fixes broke setups that don't rely on ibus, such as Hyprland.

[augustotx]

Using River (wayland window manager based on WLRoots) and it broke my accents just like @tomaspinho said. I downgraded to version 1.0 and it started working again

[sigboe]

I also have this issue on Ghostty 1.1.0 on sway (wlroots). And when I try to run an older version of ghostty it works correctly!

I tested by doing this on NixOS, but should work on other distro's if you have set up nix already, the extra experimental features flag is only needed if you don't have flakes set up.

# The commit hash for the commit before ghostty was updated to 1.1.0, so it means 1.0.1
nix run --extra-experimental-features 'flakes nix-command' --impure "github:nixos/nixpkgs/666e1b3f09c267afd66addebe80fb05a5ef2b554#ghostty"
# verify by passing --version flag to ghostty
nix run --extra-experimental-features 'flakes nix-command' --impure "github:nixos/nixpkgs/666e1b3f09c267afd66addebe80fb05a5ef2b554#ghostty" -- --version

# The commit ghostty was updated to 1.1.0
nix run --extra-experimental-features 'flakes nix-command' --impure "github:nixos/nixpkgs/433c039f3bafd25c68a4df74397e407d977b0daa#ghostty"
# verify by passing --version flag to ghostty
nix run --extra-experimental-features 'flakes nix-command' --impure "github:nixos/nixpkgs/433c039f3bafd25c68a4df74397e407d977b0daa#ghostty" -- --version

(also comment for future reference, to find the hash, I checked on search.nixos.org, searched the package name, ghostty in this case. Clicked the source link, this takes you to the source of the package, not the program it self. Then i pressed the Blame button to get git blame, scrollet to the line where the version number was changed, there I could click on the commit message to go to the commit, or if I wanted to browse further back in time there is a blame prior to change. After I opened the commit by clicking the commit message, I got the diff of the commit that changed the version. There is information about the parent commit, which means the commit prior in this case, clicked that, which is other than being the prior commit completely unrelated. Personally I got the commit hash from the URL, there is also a button on the page to copy the full commit hash.)

[Biganon]

Having the same issue with ghostty 1.1.0-arch on Arch with sway 1.10.1 and ibus 1.5.31-2. Unable to enter a letter with a circumflex, such as â or ê. There seems to be a finicky way to enter them after hitting Alt Gr, but I can't reproduce that every time.

edit : fixed in 1.1.2-arch