Kitty: Deleting by word on macOS / Sending custom bytes.

[alextes]

Deleting words works when using option, however, since I use a lot of cli tools I have that set as alt / meta. Sadly that breaks deleting by word. Now from iTerm it seems the key is sending a magical hex code (0x17) but I have no idea how I could possibly map this 😞 .

Loving kitty so far 😄 !

[kovidgoyal]

You can map any key combination to send any bytes you like using the send_text mapping, see kitty.conf for examples.

[alextes]

Perfect, found it, thank you!

[alextes]

Solution is adding the following to your kitty.conf:

# remove word
map alt+backspace send_text all \x17
# remove line
map super+backspace send_text all \x15
# move to beginning
map super+left send_text all \x01
# move to end
map super+right send_text all \x05

@kovidgoyal interested in a PR for an option? I'm guessing just the first one, others might be less common, and only in kitty. I feel this is crucial since we use it everywhere. Like here on GitHub, but maybe that's just me. Perhaps it's best if we wait and see how many 👍 it collects and take it from there 😄 .

[kovidgoyal]

The default shortcut (in all terminals) for backspace word is ctrl-w. You can check that with stty -a which should show you

werase = ^W

Is alt+backspace a macOS thing? (I'm not a mac user)

[alextes]

Says werase = ^W; yet doesn't work.

I've been away from Linux for too long 😅 . In the textbox I'm writing in right now, option+backspace (actually called 'detele' on a mac) works as delete word.

Thanks for adding it in any case!

[sergei-dyshel]

Just stumbled on this issue after upgrading Kitty version and I'd like to object :smile:

In fact Alt-Backspace does not backspace word in a same way as Ctrl-W does (as 48377f3 commit message states) not in Gnome-Terminal, nor in any other terminal I've used, at least on my Linux setup (Fedora 25).
Moreover, according to Bash docs these keys do different kinds of work killing:

• Ctrl-W kills words bounded by non-whitespace.
• Alt-Backspace kills words consisting of alpha-numerics only.

For now I have

map alt+backspace send_text all \033\177

in my kitty.conf but IMHO changing widely accepted behavior in favor on MacOS's quirks is not appropriate.

[kovidgoyal]

I highly doubt there is widely accepted behavior for anything on linux :)

For instance, on my linux system showkey -a reports that alt-backspace sends the bytes
0xc2 0x88 in xterm and 0x1b 0x7f in gnome-terminal and nada in the linux console.

werase on the other hand, is at least consistent among different terminals. If you can point me to some documentation somewhere that establishes a "standard" for what bytes alt-backspace is supposed to send, I'll be happy to revisit. As it is, the convention on the OS with the order of magnitude larger userbase wins.

[sergei-dyshel]

I agree that calling it "widely accepted" was more of an observation based on personal experience and also various internet discussions I've read, than statistically proved statement :smile:

I also don't think there may be any "standard" for Alt-Backspace, at least because there is not standard code for just Backspace itself (Backspace/Delete is well-known problem on Unix that causes a lot of confusion and inconsistency between distros/terminals/Unix flavors).

As for userbase I don't think I can measure Linux vs MacOS even approximately, but it's quite possible that number of Mac users accustomed to Option-Backspace is bigger that number of Linux-Bash users accustomed to Alt-Backspace in the sense I've described.

So it's up to you to decide :smile:

So, to continue my IMHO, I see it pretty natural that Alt-<key> translates to Escape followed by . 0x1b 0x7f is consistent with this behaviour since Backspace alone sends 0x7f on all terminals I've tried (Gnome terminal, Konsole, Alacritty, urxvt, just to name a few), though as I said earlier this not a standard but just default on these terminals. xterm is exception here because it uses Alt for entering Unicode characters (simple googling shows this Arch wiki and also big number of questions on StackOverflow on how to make Alt key behave "normally" in xterm). After "fixing" xterm shows 0x1b 0x7f too.

Again, it's not big issue for me since we can remap anything, and not that I hate Mac, I just like Kitty and want it to be perfect )))))

[kovidgoyal]

Well, I suppose we can simply change the default behavior based on platform. I'll look into it when I have a moment.

[egmontkob]

I'm using Alt+Backspace all the time, and hardly ever Ctrl+W. In fact, I've just realized from a previous comment here that these two are not the same in bash :)

As far as I recall, xterm is the only one (apart from Kitty) where Alt+Backspace doesn't work out of the box for removing the preceding word, but inserts ÿ instead. A *eightBitInput: false "fixes" it for me. This 8th bit thingy should have died a long time ago anyway, at the latest with the widespread deployment of Unicode/UTF-8.

I'd argue that prefixing 0x08 or 0x7F (whichever Backspace generates) with 0x1B is pretty much standard.

[kovidgoyal]

Not correct alt+backspace does work in kitty for removing the previous word. In fact it works much better than in terminals that generate x1b + BS because those terminals have to rely on client programs correctly interpreting that escape sequence as remove previous word, which, for example bash does wrong (in the sense that it considers the previous word to be only alpha numerics). Similary zsh and vim dont work with x1b + BS. kitty instead maps it to ^w which is (as per stty) erase word and works in bash and zsh and vim out of the box. It is all the linux terminals that get this wrong.

However, I dont have a horse in this race as I dont use alt+backspace (ctrl+w is much easier on my wrists). So I am willing to change kitty's default behavior on linux to match other terminals, even though the other terminal's behavior is arguably incorrect.

[egmontkob]

Not correct alt+backspace does work in kitty

I have an old kitty (0.4.2) due to harfbuzz dependency. Here it works like backspace. Thanks for the clarification that it has been change since!

it works much better [...] have to rely on client programs [...] kitty instead maps it to ^w which is (as per stty) erase word

It's indeed an advantage of kitty's approach that it works in cooked mode too.

which, for example bash does wrong (in the sense that it considers the previous word to be only alpha numerics)

It's rather a matter of taste, and I happen to prefer bash's Alt+Backspace behavior (maybe I just got used to that).

as I dont use alt+backspace

whereas I don't use kitty... I'd just generally wish to see the terminal emulation world become more coherent than it is today. But in the end it's your call. Thanks for considering this possible change, whatever your decision will be.

[kovidgoyal]

@egmontkob No worries, I too am sympathetic to the cause of getting terminal emulators to behave similarly for these kinds of things, which is why I agreed to look into changing it.

[lucasalencar]

I have added alt + arrows as well to move through words.

# move word with left arrow ESC+b
map alt+left send_text all \x1B\x62

# move word with right arrow ESC+f
map alt+right send_text all \x1B\x66