Delete behaving as Backspace in neovim on macOS when enabling enable_kitty_keyboard, works in kitty

[dev-zero]

Hi everyone,

I am not entirely sure yet whether this is a bug and if yes in which application. But maybe someone could shed some light on it.
As soon as I set enable_kitty_keyboard = true in wezterm, the Delete key on my external keyboard starts to behave like the backspace key in nvim, rather than forward delete. Both wezterm and another editor (nano) behave as before. This is with neovim 0.9, wezterm 20230427-063511-9bc7de70 on macOS 13.3.1.

Running the same neovim in kitty does not show this changed behavior, there delete works as before.

Thanks in advance,
Tiziano

[wez]

Please try the latest nightly build, which has improved support for the kitty keyboard protocol

[dev-zero]

@wez thanks for the update, unfortunately it doesn't fix it, using wezterm 20230722-103103-a07ab883

[cbirchinger]

I just ran into this today on Linux with a WezTerm build 20231228-084719-ff274374

"nvim -u NONE -U NONE -N -i NONE" with "enable_kitty_keyboard = false" works normal but changing to "enable_kitty_keyboard = true" will cause the delete key to do backspace functionality.

However, this could of course also be a NeoVim bug. I don't have kitty to do a cross check.

[SecretPocketCat]

Same thing goes for helix. Works OK in Kitty & Alacritty.
Any known workarounds for this?

[1mamute]

This is also happening to me. The terminal is deleting forward as normal, its just happening in neovim (version 0.9.5).

> wezterm --version  
wezterm 20240203-110809-5046fc22

With config.enable_kitty_keyboard = true

> echo -e '\e[>1u'

> cat
^H

Pressing BACKSPACE afterwards erased ^H in one stroke.

With config.enable_kitty_keyboard = false

> echo -e '\e[>1u'

> cat
^[[3~

Pressing BACKSPACE afterwards erased each character of ^[[3~ one stroke at time.

If there's anything I can help with to provide more information let me know!

[rrveex]

#5025 fixes this (on linux)

[benjivm]

This is happening to me as well while in neovim on mac, but it works just fine in the shell. Is there a solution?

[cbirchinger]

I've been using this patch for a while. It's maybe not "the correct" way but it has been working for me for a year:

From 855957ec82a28621b8287ac595ac6decd36149c1 Mon Sep 17 00:00:00 2001
From: Jacek Swierk <[email protected]>
Date: Sat, 17 Feb 2024 13:13:01 +0100
Subject: [PATCH] fix: send correct codes with del and esc

With kitty keyboard protocol enabled, both DEL and ESC key sends legacy
keys - DEL sends ^H and ESC sends ^[. To be in line with kitty keyboard
protocol, they should send "CSI 3 ~" and "CSI 27 u" respectively.
---
 wezterm-input-types/src/lib.rs | 56 +++++++++++++++++++++++++++++++++-
 1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/wezterm-input-types/src/lib.rs b/wezterm-input-types/src/lib.rs
index b3298bad6aa..4231262674d 100644
--- a/wezterm-input-types/src/lib.rs
+++ b/wezterm-input-types/src/lib.rs
@@ -1648,8 +1648,9 @@ impl KeyEvent {
         {
             // Check for simple text generating keys
             match &self.key {
+                // Don't send legacy codes with DEL and ESC
+                Char('\x1b') | Char('\x7f') => {}
                 Char('\x08') => return '\x7f'.to_string(),
-                Char('\x7f') => return '\x08'.to_string(),
                 Char(c) => return c.to_string(),
                 _ => {}
             }
@@ -3124,4 +3125,57 @@ mod test {
             "\u{1b}[102;14u".to_string()
         );
     }
+
+    #[test]
+    fn encode_issue_4785() {
+        let flags = KittyKeyboardFlags::DISAMBIGUATE_ESCAPE_CODES;
+
+        assert_eq!(
+            KeyEvent {
+                key: KeyCode::Char('\x7f'),
+                modifiers: Modifiers::NONE,
+                leds: KeyboardLedStatus::empty(),
+                repeat_count: 1,
+                key_is_down: true,
+                raw: None,
+                #[cfg(windows)]
+                win32_uni_char: None,
+            }
+            .encode_kitty(flags),
+            "\u{1b}[3;1~".to_string()
+        );
+
+        assert_eq!(
+            make_event_with_raw(
+                KeyEvent {
+                    key: KeyCode::Char('\x7f'),
+                    modifiers: Modifiers::NONE,
+                    leds: KeyboardLedStatus::empty(),
+                    repeat_count: 1,
+                    key_is_down: true,
+                    raw: None,
+                    #[cfg(windows)]
+                    win32_uni_char: None,
+                },
+                Some(PhysKeyCode::KeypadDelete)
+            )
+            .encode_kitty(flags),
+            "\x1b[57426;1u".to_string()
+        );
+
+        assert_eq!(
+            KeyEvent {
+                key: KeyCode::Char('\x1b'),
+                modifiers: Modifiers::NONE,
+                leds: KeyboardLedStatus::empty(),
+                repeat_count: 1,
+                key_is_down: true,
+                raw: None,
+                #[cfg(windows)]
+                win32_uni_char: None,
+            }
+            .encode_kitty(flags),
+            "\u{1b}[27;1u".to_string()
+        );
+    }
 }

[benjivm]

Hi @cbirchinger this looks like you're patching the wezterm source code directly and using your own build?

Thank you, I added this to my wezterm config and it fixed the issue:

keys = {
  {
    key = 'Delete',
    mods = 'NONE',
    action = wezterm.action.SendString '\x1b[3~',
  },
  {
    key = 'Escape',
    mods = 'NONE',
    action = wezterm.action.SendString '\x1b[27u',
  },
}