wezterm VS kitty

wezterm (Linux, Macos & Windows)

A month ago, I came across WezTerm, a new GPU-accelerated, cross-platform terminal emulator written in Rust (and I’m not a Rust fanboy, for real!). It piqued my interest, so I decided to give it a try.

Select all seems a bit risky in a terminal because it could contain way more information than you'd expect.

e.g. I want to `cat` a file to make sure i've got the right one, but I accidentally cat a full 1gb sql backup rather than the tiny 50 line script I was expecting. Sometime later, I try to select all, copy, switch application, paste for some reason but now I'm stuck waiting for 1gb to copy over

Personally I'm a bit more cautious about copying from a terminal.

Either way if that's what you really want to do, you can check the repo to see how other people scripted it into wezterm:

https://github.com/wez/wezterm/discussions/2026

I used Lua for years to configure my awesomewm desktop environment. Then, I started using it to configure my Wezterm. Since I bumped into an Emacs bug (lsp-mode bug to be fair), I switched quickly to Neovim after 20 years of Emacs, and I am using Lua to configure my Neovim. Last but not least, OpenResty gives my Nginx superpowers with Lua.

wezterm (Linux, Macos & Windows)

I started using wezterm recently and really like it. It's cross platform and supports sixel graphics.

https://github.com/wez/wezterm

While WezTerm is a great terminal with sane defaults, it doesn't provide the default key binding to open the configuration file and edit it. That is understandable, everyone may have their own preference for that. Here we will figure out the recipe that would work everywhere and abide by modern standards.

Yeah, it's only for nvim or for your own lua projects.

For WezTerm annotations, afaik there is currently only an open issue without much progress: https://github.com/wez/wezterm/issues/3132

> [...] waiting for one or more terminal emulators to get together and add some ridiculous new escape codes [...]

I'm definitely of the opinion[0] that we haven't yet reached the limits of the "terminal emulator" UX paradigm.

The past few years do seem to have seen a resurgence in terminal emulator innovation due in part to a combination of new languages, the prevalence of GPUs, and a realisation that many of the existing terminal emulators weren't interested in any innovation in certain directions.

I've particularly been interested in the possibilities provided by the Terminal Graphics Protocol (which I discuss more in the linked comment).

A couple of years ago I switched to WezTerm[2] due to a combination of its graphics support, implementation language (Rust) and that its main developer seems to be interested in a combination of both solid support for existing standards & opportunities for innovation.

WezTerm also provides opportunities for customisation both in terms of shell integrations and of the application itself[3].

> [...] new escape codes [...]

Also, on this aspect, it may not even be necessary to create new escape codes--recently I discovered the `terminfo(5)` man page actually makes a pretty interesting read[7], in part because it lists some existing escape codes that seem like they have potential for re-use/re-implementation in the current day's more graphic-based systems.

---- footnotes ----

[0] As I mentioned in a recent comment on a thread[1] here:

"Motivated by the thought that at the current point in time perhaps the 'essence' of a 'terminal' is its linear 'chronological' presentation of input/interaction/output history rather than its use of 'text'."

[1] https://news.ycombinator.com/item?id=40475538

[2] https://wezfurlong.org/wezterm/

[3] While I'm definitely not a fan of the choice of Lua as the extension language, I have now at least hit my head against the wall[4] with it enough that I can actually get more complex custom functionality working.

[4] I've started to write up some of my Lua-related[5] notes & more general WezTerm[6] notes so hopefully it'll eventually be an easier road for others. :)

[5] https://gitlab.com/RancidBacon/floss-various-contribs/-/blob...

[6] https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...

[7] As one does. :) It was a fascinating/amusing time capsule in terms(!) of mentions of weird hardware terminal quirks that at one time ("before my time") needed to be worked around; interesting escape code discoveries; and, the mention of a term I had not thought of for decades but was at one time of importance: NLQ! :D

kitty (Linux & Macos)

The "security" practices of kitty are dubious: https://github.com/kovidgoyal/kitty/pull/3544

This one is the straw that broke the camels back for me: https://github.com/kovidgoyal/kitty/issues/4965

"Are you sure you want to close this window",

kitty (Linux & Macos)

Oh, this might be the missing piece of the puzzle for me to get rid of tmux!

I've been using screen/tmux for a long time. Recently I switched to kitty[0] locally. I like kitty a lot! But I've been stuck with tmux on my servers for session persistence.

[0]: https://sw.kovidgoyal.net/kitty/

Besides the usual Firefox/Chrome, Spotify, etc I use the following:

- Karabiner-Elements for key remapping, specifically, for making caps lock into ctrl/esc. I don't know of anything else that does this job. Everyone who remaps keys seems to use this.

- Kitty as my terminal of choice. I spend most of my time logged in remotely to a server via ssh where I attach to a tmux session. Kitty was easy enough to configure/theme and seems well-documented.

- Hammerspoon[2] for a DIY automation/keybinding/window management sys scriptable via lua. I use a private fork of this config: https://github.com/jasonrudolph/keyboard/tree/main

- Vivid[3] to make my macbook's screen brighter when outdoors on sunny days. This is important for me, since I try to spend as much time outside as possible.

[0] https://karabiner-elements.pqrs.org/

[1] https://sw.kovidgoyal.net/kitty/

[2] https://www.hammerspoon.org/

[3] https://www.getvivid.app/

It's not like Goyal doesn't accept any patches [1].

I don't use kitty myself, but many people who do seem to love it. I've come around to feel that this is truly a maintainer's judgment call. After all, they are almost always stuck maintaining the code no matter who wrote it initially, and they know better than anyone else what code they're personally comfortable maintaining.

More generally, if you like a piece of software enough, you're implicitly trusting the maintainers' judgment. You're certainly not reviewing every single line of code they write to see if you agree with it.

The miserable survival rate of hostile forks also demonstrates that even if people care enough to fork over one issue, they rarely care enough to maintain the overall project long-term, despite implicitly asking the original maintainers to do the exact same thing.

[1] https://github.com/kovidgoyal/kitty/graphs/contributors

My understanding is that kitty has an automatic (opt-out) update feature [0][1]. I don't really like the idea of a terminal doing that.

However I like the fact that kitty developer(s) actively improved the state of the terminal emulation with their new keyboard and graphic protocols [2].

[0] https://github.com/kovidgoyal/kitty/issues/2481

[1] https://github.com/kovidgoyal/kitty/pull/3544

[2] https://news.ycombinator.com/item?id=40378357

And kitty is much faster according to this: https://github.com/kovidgoyal/kitty/issues/2701#issuecomment...

Also typometer based measurements also on Linux. Shrug.

kitty (Linux & Macos)