I switched to wezterm (https://wezfurlong.org/wezterm/) a few months ago and I'm pretty pleased with it (especially the search function, which is something not many terminals support), although it still has some rough edges.

I've used kitty for quite a while but it has subtle problems with tmux that I use all the time (one of the primary reason is persistent session).

From the FAQ https://sw.kovidgoyal.net/kitty/faq/ and other GitHub issues, it seems the recommendation is not to use tmux. Since I need to use tmux, I then change the terminal emulator I use instead.

Is Kitty's startup time (~200ms) not unbearable for other people? Is it faster now or do people not spawn new terminals constantly?

I tried to try Warp, out of curiosity, and.... Are they fn kidding? A terminal that requires sign-up???

What in the actual hell.

Oh my god Fig too! Which of you is encouraging this crap??

Kitty's my daily driver on Mac (when I'm not using eshell, anyway), but on the Windows side I am actually pretty damn impressed with Windows Terminal over WSL2. I don't even bother using graphical mode on emacs in WT/WSL, it is smooth as butter and super responsive in terminal mode and aside from using Linux, I'm actually preferring it as a dev environment to a Mac these days.

In fact, it feels like there's an ever-so-slight latency when on a Mac that Windows doesn't have. At first I put it down to the keyboard feel, but even using the same keeb it feels a bit more 'squishy' on the Mac.

Also, Microsoft has their own new terminal program.

https://github.com/microsoft/terminal

> kitty I hate to be the sour consumer, but the kitty dev’s attitude I’d the main thing that turned me off kitty. Wanted to like it, couldn’t do it.

My favorite is alacritty, although kitty is a close second, not a big fan of how kitty handles fonts/colors compared to alacritty.

I wasn't crazy about the proprietary nature of Warp, but I tried it and was sold almost immediately. I can use the same modifier-key commands to select and manipulate text that I'm used to, which feels super nice. They also provide such good sessionization out of the box that I don't really feel the need to install tmux or anything like that.

Seconding kitty, a while ago I tried like a dozen of different terminal emulators and tested a lot of features including link clicking, escape code rendering, Unicode rendering and so on, and only kitty and Sakura have passed most of my requirements, with Sakura having one issue that I cannot recall that ultimately made me choose kitty. Built-in window splitting without tmux is also great. The only downside is that when you SSH into a remote machine without kitty's terminfo installed, you can't even use backspace or other common keys, which is annoying.

Both Ghostty and Terminal Click developed with zig, it seeems...

I've tried kitty twice, both times I found it confusing and went back to anything else

So, Ghostty will be BUSL, too?

Thanks for the links! Click is cool&bold in that it tries to get rid of all the obsolete baggage, pity it's in C, though

simply put, yes. but I know very well that performance can be measured in many different dimensions and ways. I optimize for speed for my own personal use-cases (vim should be fluent as well as notcurses-demo as well as cat'ing large output).

Especially cat-style benchmarking is what YT-channels like to do, right next to `time tree /`.

We do not claim to be THE fastest (unless you find out why, but pssst, don't tell anyone), because I do not want to start a performance war on some metric that is almost useless for the regular and even power user.

Input latency, oof, last time I actually took the time to check, it was similar to KDE konsole. I used some Java based tool to measure this, IIRC I've got this from an LWN article. But now, I'm not having the time to do this again, especially since I feel like there's more important stuff on our plate, that I really want to get done in 2023 (e.g. getting out the next stable release). :)

If anyone of the power users opts to re-visit perf benchmarking on the modern TEs compared to the classic ones, I'd be one amongst the first to gladly read though ;)

After using iTerm2 as my daily driver for like a decade, and then trying out some of these other "fast" terminal emulators, I was amazed at how slow the experience in iTerm2 is. I even kept alacritty around as a second terminal for a while for cases when not having iTerm2 features wasn't a deal breaker, but eventually I just went back to iTerm2. I am still aware of how slow it is, and although I tolerate it, I wish it were as fast as some of the others.

You can see the speed difference with your eyes by joining a tmux session from different terminal emulators and doing operations that redraw the whole terminal, such as searching in a less pipe.

Yes. It's common on at least Microsoft terminals to be waiting for the terminal to finish displaying the output it has been sent. I expect that it will be the same for many older terminal emulators.

> Are people frustrated by the latency of the incumbents

Yes. If you write code in vim as I do, terminal latency (snappiness) is very important. s a matter of fact, that's the main reason I paid attention to this project.

Short answer: yes.

Longer answer, there are diminishing returns, but speed definitely is a selling point. A terminal being slow is not necessarily something you notice straight away (if the software is competent in the first place; a lot of them are not). However, testing a new one with a lower latency and fewer buffering issues is when you feel it, and then it is difficult to go back.

Latency doesn't bother me too much, but throughput can really matter if I'm running a particularly verbose command. Often program speed is limited by how fast the terminal is able to clear the stdout pipe. This is especially true when running commands inside emacs "build" window (which is running who-knows-how-many regexs). If it's more than ~10,000 lines long then an instant command can be slowed down to more than 10 seconds.

I’ve never been able to perceive the difference. I use iTerm2 and I can’t perceive how it could be faster.

Seems to be a windows/mac problem. In Linux I've never really been bothered by it in at least 20 years

> Are people frustrated by the latency of the incumbents?

Not me, no. And I'm not even frustrated by pretty much anything. I have some Cygwin SSH sessions on the go and I'm running 'screen' in those terminals. It works and has done since the '90s.

Long term Gnome Terminal user, I recently tried Alacritty, ugh, massive difference. Went back to Gnome after a couple of days. Like typing through molasses. Terminals can be slow.

I only care about latency from pressing Ctrl+alt+t to typing the first char of the command.

xfce4-terminal does just fine for this. So I just use that.

On Windows, yes. Not on Mac or Linux though.

FYI for editing multiline inputs there is a readline key command edit-and-execute-command that opens your $EDITOR with the currently typed command. I mapped it to C-x C-e, not sure what is the default key, if any.

For history I recommend fzf, it's easy to integrate and has one of the most efficient interfaces I've seen. Replaced my ctrl-r with it.

For copying I personally use a tmux binding that dumps the current screen into vim, letting me navigate quickly with easymotion and a mapping that automatically synchronizes the @t register with tmux clipboard.

There are better experiences (e.g. my shell has vi mode which is much nicer for editing multi-line inputs, I'm sure if I could be bothered to learn emacs/readline shortcuts that'd be another set) but they're not easily discoverable and a bit unevenly distributed.

> It would be nice if someone worked on actually improving the terminal experience.

Contour. Oh, sorry, I mean: To be honest? There are plenty of young terminals that work on that, it's not just Contour, but also WezTerm, foot, Ghostty, Warp, and Terminal.click (even though I am strongly against their architecture). Also Charm and Fig should earn an honorable mention.

> Selecting, copying and pasting text is still pretty awful

Use the vi-like normal mode in Contour and that should(tm) fix almost all of the above problems. At least I have almost never touched a mouse again on Contour since I've implemented modal input in Contour. Well, I use the mouse, casually for scrolling and procrastinating by randomly clicking around. :)

> (why is the cursor an entire block rather than a I bar?).

this is configurable in recent terminals

> Editing multiline inputs is awful.

this should be implemented by your shell or readline, in case you want to improve here. your TE has nothing to do with this except that it provides the tools to realize that on the screen :)

> Navigating history is so-so (even with McFly etc.).

This is the job of the shell/readline.

> Anything more complicated than left/right/up/down fails half the time and dumps control characters instead.

I really cannot related that claim to anything I am experiencing in my own life. Sadly.

> Why are terminals always stuck in the 70s? Can I get a modern terminal?

To be fair, they are not named "emulator" for fun and giggles. But I agree, not every VT sequence or semantic should be blindingly implemented. Especially the Unicode case on Terminals were always a fight against the historian terminal emulator developers. I asked myself why a lot on that matter. My theory? Because it potentially requires those existing terminals to fully re-write their core code base in order to be fully (as full as it gets) Unicode aware.

Have a look here for a baby-step forward: https://github.com/contour-terminal/terminal-unicode-core

This is implemented by 4 terminals (Ghostty, WezTerm, foot, Contour). One bite at a time I guess. Let's just stay positive, we can't break the world! (Terminal.Click? You listening?) But we should certainly break here and there when it makes sense and also not blindingly implement the 70s again. The GUI has also good moments and can live next to the TUI ;)

> Editing multiline inputs is awful.

Outside of "line at a time" i/o (a rarely used mode where an entire line is edited locally and then sent to the host), most of what users see is as interactive is controlled by the program you are interacting with. The terminal just takes commands from the host and does what it is told. BTW, line at a time mode isn't used that much. The only thing I use that uses line at a time mode is telenet in LINEMODE.

> Navigating history is so-so

Yes, that is because the program you are likely interacting with where history is relevant implements it's own repl or command line (i.e. bash, zsh, python, etc...) and it is responsible for it's own history and may implement it completely differently than say, bash or zsh.

> Why are terminals always stuck in the 70s? Can I get a modern terminal?

We do have a modern terminal: the web browser... and it's pretty nice.

There have been a ton of tries at more modern terminals, but ultimately, they end up really being limited by the software running in the terminal session. In the 90s we had a ton of commercial terminal emulators that would allow you to create full guis, complete with dialogs and forms. In the 00's there were a few tries at terminals that would allow html output and embedding of html forms for input (can't remember the names of them). I suppose there's also the whole X11 thing... which is so good enough that it's really hard to kill.

Let's get back to character mode:

A lot of interactive terminal software is built using different libraries - so sometimes you get a terminal gui based on ncurses, terminal.gui, or something else... here's a list: https://github.com/rothgar/awesome-tuis#libraries. Most of these libraries try to use most of the features in your terminal emulator, but often, just use stuff that is in everything.

For command line programs (i.e. just type a command), a lot of the experience is dictated by the parser used by the tool and whatever the underlying operating system has for passing arguments. Some shells and terminal emulators (like iTerm2 on mac) try to smooth this out, but again, there's a lot of variety in command line parsers.

Probably the biggest modern improvement in the shell world was gettext and various command-line completion libraries which allows command parameter completion if the developer supports it or uses a parser that supports completion. But none of this is the terminal itself doing the work.

Fwiw, iTerm2 has a "copy mode" which lets you navigate around and yank the visible terminal and scrollback with vim bindings

I don't know. If the script is legible, that's an executable (and therefore probably tested), exact documentation.

edit: yep, I just took a look and can confirm, it takes a few seconds to get the list of dependencies for several distributions. It's way better than most readmes.

wezterm has a unique great feature of programmable configuration (lua), which allows (among many things) to have custom keybindings depending on the foreground process, then there is also some keybinding modality (in Contour as well), then some have quick command panels, then there are various levels of tab support, then there are a bunch of other UI improvement...

But if iTerm2 has too many features, implying you don't care that much about them, you might not be invested enough to learn about the difference (there are many little things and not a great comparison of various terminals for an easy read)

I was going to comment something similar. I use iTerm2 day to day for work, and gnome-terminal on my personal Linux box.

What's a compelling reason to switch terminals? Or maybe: is there a compelling reason not to switch?

I like native tabs so that I can compartmentalize multiple tmux sessions. Alacritty with tabs would be perfect. Kitty seems to be that - but it’s got some oddities of it’s own.