The "Delete" key doesn't work as expected

[asm0dey]

In this GIF, you can see that deleting anything with the "Delete" key is very slow: it takes 2 keystrokes for each deletion.
Also, If I type something like "Delete" and then "Space", I see a symbol like this: ء

It doesn't happen with Backspace

[mitchellh]

Is this a terminfo issue? https://ghostty.org/docs/help/terminfo

I can't reproduce this.

[asm0dey]

It's reproduced on the local machine in ghostty with zsh without sudo, so shouldn't be

[asm0dey]

I guess anyone would notice it, so it's something specific to my environment, but I'm not even sure which info would be helpful for debugging

[veltza]

I have the same problem on EndeavorOS (Arch) as I also have to press the Delete key twice in shells. Interestingly, the Delete key on my numpad works fine.

I ran kitten show-key -m kitty on both Kitty and Ghostty and noticed that the normal Delete behaves strangely, but the numpad Delete works correctly:

Kitty

DELETE PRESS 
CSI 3 ~

DELETE RELEASE 
CSI 3 ; 1 : 3 ~

KP_DELETE PRESS 
CSI 57426 u

KP_DELETE RELEASE 
CSI 57426 ; 1 : 3 u

Ghostty

DELETE PRESS ء
CSI 3 ;  ; 1569 ~

DELETE RELEASE
CSI 3 ; 1 : 3 ~

KP_DELETE PRESS
CSI 57426 u

KP_DELETE RELEASE
CSI 57426 ; 1 : 3 u

[asm0dey]

For me it works the same!
And in Konsole it's

DELETE PRESS 
CSI 3 ~

DELETE PRESS 
CSI 3 ~

[cestrauss]

For me, the following works: rename or remove the ~/.cache/gtk-4.0 directory.
Moreover, I can "infect" other unaffected users in the same machine by replacing this directory on their caches with the contents of mine.
I'd zip it and paste it here, but need to find out first if it can contain any private data.
By the way, on ghostty 1.1.0 the behavior has changed: the delete key does nothing, although it does block all further input until I press it again. Even so, deleting ~/.cache/gtk-4.0 still solves it.
I'm on Archlinux, and installed ghostty 1.0.1 and 1.1.0 from the official Archlinux repository.

[olefasting]

This does not seem to be related to the gtk cache, specifically, as I am on kde and have no gtk-4.0 cache directory.

I get the same result as @asm0dey and I am using a us key layout on a hhkp (if that can be relevant)

EDIT: the fact that the numpad delete key works makes sense, as it is not regarded as the same key internally

[olefasting]

Hello again. It seems this is an issue I now have with all terminals, and it is connected to terminfo (and shell implementations, to some degree, I believe).

This page sheds some light:

fish-shell/fish-shell#2139

A hacky fix for the issue with delete not working, is to map a keybind in zsh, sending a delete-char when the delete key is pressed. This seems to be an issue of tech debt from the days of physical consoles and there seems to be no real solution, except for deviating from these old standards.

EDIT: Simply overriding the TERM variable, setting it to xterm-256color, solves the issue. I am assuming this is not ideal, as I have seen ghostty setting this to other values when I ssh, for example. Any thoughts?

Might also be worth noting that my .terminfo only contain settings for xterm-256color, not xterm-ghostty, or whatever it is I've seen it using before.

[taylrfnt]

I have a custom keyboard with some non-standard mappings for quite a while now, and I noticed back when I started using it that when I map my delete key it didn't always send the right code for Del.

I've had this in my zshrc for a long time, it's just the code that my delete key sends when mapped as delete bound to the key that Zsh understands. There's a link in there too with an explanation of how to get your value, and the history behind this.

# fixing delete key
# https://superuser.com/questions/997593/why-does-zsh-insert-a-when-i-press-the-delete-key/1078653#1078653
bindkey "^[[3~" delete-char

It may have something to do with Ghostty's implementation of fixterms, but I can't really say that confidently, and I have had this config in my shell long before I started using Ghostty, so I can't really test that cleanly without nuking my entire machine config :(

[00-kat]

It may have something to do with Ghostty's implementation of fixterms, but I can't really say that confidently

Nothing like that. The delete and backspace keys have historically had multiple different encodings. The terminfo specifies which one a specific terminal emulator uses, though.

[olefasting]

I have a custom keyboard with some non-standard mappings for quite a while now, and I noticed back when I started using it that when I map my delete key it didn't always send the right code for Del.

I've had this in my zshrc for a long time, it's just the code that my delete key sends when mapped as delete bound to the key that Zsh understands. There's a link in there too with an explanation of how to get your value, and the history behind this.

# fixing delete key
# https://superuser.com/questions/997593/why-does-zsh-insert-a-when-i-press-the-delete-key/1078653#1078653
bindkey "^[[3~" delete-char

It may have something to do with Ghostty's implementation of fixterms, but I can't really say that confidently, and I have had this config in my shell long before I started using Ghostty, so I can't really test that cleanly without nuking my entire machine config :(

I managed to fix this after a lot of fiddling, but narrowed it down to the following steps:

1. Set your TERM variable to 'xterm-256color' and verify that input is working as expected
2. Extract terminfo using the following command:
   $ infocmp $TERM > terminfo.src
3. Reimport for current term (xterm-256color), using the following command:
   $ tic terminfo.src
4. Copy the profile created for ghostty using the following command:
   $ cp -r ~/.terminfo/x/xterm-256color ~/.terminfo/x/xterm-ghostty
5. Set TERM to 'xterm-ghostty'

I did a big, system-wide update yesterday and I am unable to reintroduce the problems by reverting these steps, so I might be wrong about these resolving anything, so your mileage may vary....

[taylrfnt]

I suppose that's one way to approach it, but I don't know that overwriting ghostty's terminfo is really the easiest or most stable means to solve this issue.

Mapping the delete key code in your shell config should serve as a persistent fix and not interfere with any changes between xterm-256color and xterm-ghostty. I assume the maintainers opted for a custom terminfo entry for a good reason :)

[jeffclayton]

someone mentioned the terminal type change method - so here is a small script to put in .zshrc to fix it
(i use more than one terminal depending on my machines so I needed a way to differentiate)

in .zshrc:

fix mac backspace not working in ghostty by changing terminal type

if [[ "$TERM" == "xterm-ghostty" ]]; then
export TERM=xterm-256color
fi

In .bashrc:

if [ "$TERM" = "xterm-ghostty" ]; then
export TERM=xterm-256color
fi

[00-kat]

…or use term:

term = xterm-256color

[jeffclayton]

update:

it did not work for me before so I reinstalled (latest version)

add the command from 00-kat to your configuration (and reload it)

so if you want to change it permanently for the app this method solves it