There are lots of terminal projects recently. Ghostty (https://mitchellh.com/ghostty) and Terminal Click (https://terminal.click) come to mind. Also Warp and Fig but they don't appeal to me because they're proprietary (and Fig got acquired by Amazon). I've been very happy with kitty (https://sw.kovidgoyal.net/kitty/) for years and it would take a lot to make me switch.
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.
The one I encountered is color problem. I can never get xterm-256color works reliably and has to use screen-256color which supports lesser features such as italic.
Running btop within tmux using kitty also has color problems, but Alacritty also fails at that.
I had a long battle with making kitty work with tmux. I settled on the following in ~/.tmux.conf, before moving to wezterm for good. Maybe it fixes things for you, too:
I tried the first line and in some situations (specifically with some remotes, i.e. kitty -> ssh -> tmux with that 1st line) it still won't fix it.
I gave up kitty because the author obviously don't like tmux and is advising users not to use it. So it is more like a choice between kitty and tmux. Giving up kitty is easier for me in terms of features and time for retraining.
What's your reason to migrate from kitty to wezterm?
> What's your reason to migrate from kitty to wezterm?
My reason to no longer using kitty is simple: I don't like having to copy kitty's terminfo data to every single system I connect to in order to have my terminal work.
It's fine for those few systems I very often connect to, of course.
But I also connect to ephemeral systems, sometimes for a short session, and the toil and friction inherent in having to do that just isn't worth it.
Sure, "kitty +kitten ssh ..." can work in most people's scenarios. Didn't quite work in mine, due to various intricacies about my ssh setup - multiple ssh keys, handled mostly by ssh-ident.
wezterm Just Worked for me. As I got "back" to also using other systems like Windows and MacOS, it Just Worked there, too. No fiddling with terminfo, no fiddling with $TERM, either.
I tried your solution using one remote server that I had trouble with before and it works! That's really great. This probably solves enough problems with kitty for me that I can use it until I find a better solution. (I am using Alacritty at the moment but it has other problems so that I have to use kitty as fall back for some situations.)
Colors in terminals are tough. There's the terminal, then the shell, then tmux, then vim, and you want all of their configs in concert even when you're switching between light and dark one or twice a day. Colors are tough in general. Even the browser color story kind of sucks. Dark reader goes a long way, but not enough
Right, I sort of understand that (not the details). I'm sympathetic to the kitty author, who explains why other terminals and tmux are doing things wrong, etc.
I guess it is especially messy in the terminal, reading a little bit into the issues and it just feels like a ton of legacy hacks between different implementations.
And comparing that to the browser is interesting. Both are "ubiquitous"—terminal emulator for cli/TUI, and browser for GUI. May be because of there generality / ubiquity, it is messy and impossible to "make it right".
> That's a pretty hyper-optimized life, when 0.2 sec to get a command line is a problem.
This made me chuckle :D. I supposed you're right. On my work rig, 200ms is a dream, so I suppose kitty would be great.
For personal programming, I use i3 and sway. The latency difference between my work mac and personal Linux is insane. Every little bit feels like molasses on Linux since it's the lowest latency system I've ever used.
Great point. I was using i3/sway which is not conducive to terminal tabs or panes, but on my mac, kitty does sound pretty good, and 200ms is way better than what I'm getting now
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.
I really like Windows Terminal too. The one issue I have is that I have Ubuntu as the default session and when I open the terminal from the start menu (i.e., hit command key, type "terminal", and hit enter), it opens but loses focus. The only way to remedy it is to disable WSLg (GUI support). It's a long standing bug and a weird one at that.
Yeah, that and sometimes the WSL session takes forever to boot up (a good 10+ seconds for the first time, for me).
Once it's working it's fantastic. I don't know what it is with MacOS, unless they're subtly animating keypresses or something. Linux is as responsive as Windows is too. It's a wired keyboard so nothing to do with bluetooth.
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.
The problem is that Warp is closed source, requires a log in, has extensive telemetry, promised to go open source but never did and has raised 78M from VCs including 50M from Sequoia, the FTX people.
Indeed, VCs will want a return on their investment at some point, and it doesn't seem like simply sharing some terminal commands in the cloud with your team will be enough to justify that valuation. This is especially true as the Zero Interest Rate Phenomenon of the last 15 years is now over.
Personally I'd never use something VC backed for something so critical to my productivity.
Having never heard of Warp and wondering what would get VCs to give that much to a terminal project I just took look at their website and it’s obviously the AI/LLM aspect.
With that said does anyone know which open source projects are looking at LLM integration. It’s not a bad idea.
I took a look before this year and it used to be that their value proposition was more so geared towards sharing terminal inputs and outputs easily. Now they seem to be leveraging OpenAI APIs instead as their main value prop.
However, I still don't really see why someone would pay 12 bucks a month for that when they could just pay a little bit more for full blown ChatGPT and use AI for much more than terminal commands (and there are already terminal and vim plugins to directly query GPT with your API key, which is orders of magnitudes cheaper than Warp). It seems like a product that has no clear target market or target usage, seems more like a feature than a full product.
Thankfully it doesn't run it, it just inserts the commands into your prompt. It's kinda nice but I've also been using the terminal for like 12 years, so I don't find myself relying on it very often.
I can just run Llama locally for that, no VC required (and indeed there are plugins which do exactly this already). Llama and other local LLMs are being optimized to run on the CPU on less than 1 GB of RAM so it's not as if only those with beefy GPUs can do so.
Agreed and the part I’m missing is these plugins which do this. Any suggestions or recommendations would be interesting to hear. Which terminals and which plugins etc.
> I can use the same modifier-key commands to select and manipulate text that I'm used to, which feels super nice.
I know this is not a complete solution, but just in case you weren’t aware, the keybindings in GNU Readline are nearly entirely configurable[1]. Getting some of the keybindings to work could require digging into serial terminal arcana[2], unfortunately, but here a terminal emulator that supports either the Kitty keyboard protocol[3] or the (venerable if impressively badly documented) modifyOtherKeys feature[4] could make things easier (messing with the serial driver[2] seems an overreaction to me, and you can’t get acceptable Ctrl-C behaviour that way anyway). The “new” terminal emulators mentioned in this thread (alacritty, contour, kitty, wezterm) should be able to do the trick, and of course xterm as well (probably rxvt too?); tmux compat needs help, though[5].
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.
I went wezterm because kitty wasnt always playing nice with tmux and i dont think i would go back at this point there is something i juat like more about wezterm i cant put my finger on.
I am always pleased to see code that is reasonably clean and uses modern C++.
Sixel support is also nice to see. For all its faults, I think it's the only pixel graphics extension that currently has a chance of widespread adoption.
I am curious if the authors have made any attempts to quantify "fast". Are there any benchmarks? In particular, I would love to see some input latency comparisons.
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.
The slowness is noticeable often enough in simple typing latency, but there's definitely a spectrum as to how much people notice or find it frustrating. On the one end there's the people that won't use anything but xterm, while on the other there's people who don't care about the seconds of latency for some remote development setups.
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.
Most older terminal emulators tends to do fairly well. E.g. on Linux, rxvt tends to be one of the fastest. Many older terminals tends to do well not least because many older terminals implements jump-scrolling properly (scroll multiple lines at a time before updating the screen if the rendering doesn't keep up) because there are even escape codes to turn that on/off.
There's a weird "bathtub curve" when it comes to terminal speed where the oldest tends to be well optimised in terms of tricks to minimise rendering, the newest all tend to concern themselves very much with rendering smart, but often miss the old-school tricks, and quite a few of the ones in the middle are just really naive about everything.
> 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.
Ya, there was a very noticeable VImprovement (lol, sorry) switching from iTerm to Alacritty. I'd never heard of this project before, looks really interesting.
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.
Most of the time people only notice the slowness if they are in the habit of regularly letting huge amounts of output stream to the terminal, so it really depends on how you use your terminal. I agree with you - for me terminal speed was a solved issue in mid 1980's, and has not been an issue since.
The speed of Gnome Terminal and Konsole on Linux along with Microsoft Terminal on Windows didn't bother me until I tried a couple of the newer faster terminals. Now all 3 seem slow to me.
It’s not a Windows/Mac thing. There are definitely slow terminal emulators for Linux as well. I’m quite sure you wouldn’t want xterm as your daily driver.
I use exactly that. It's fine for me and I'm very much a terminal first person.
Maybe people have extremely fancy shell setups? Perhaps it's a font thing that slows it down? Can you demonstrate?
I'm usual a tmux/zsh/vim user (although I've promised to switch to emacs for years :( )
I just timed my xterm. I'm displaying about 2.3MB/s of characters.
Basically here was my test
$ dd if=/dev/urandom bs=10M count=1 | hexdump -C > /tmp/test
$ ls -l /tmp/test
-rw-r--r-- 1 chris chris 51773449 Oct 8 09:32 /tmp/test
$ time cat /tmp/test
... wait wait wait ....
51773449 / (total time) / (2^20)
Now this of course depends on the size of the window. I'm on a 4320x3840 dual 4k monitor and the window geometry was 1334x928 for this test.
I acknowledge this computer (i7-8650U ~ 2018 thinkpad with a boring UHD Graphics 620) is capable of faster output but the xterm featureset is vaaassstt (albeit extremely complicated) and I've found the other terminals to be lacking.
My only faithless move away from xterm was probably 17 or so years ago with rxvt when I was on a laptop with ballpark 16MB of memory. It's memory footprint and startup time was way smaller probably for its total lack of features and unicode support. That made a difference on my Toshiba Protege 120mhz pentium I was using at the time.
When I was a macOS and a Windows developer, slow terminals were definitely a problem though
To be honest, refterm was a bad idea to begin with. It's not a terminal, and it eventually also stated that in its README.md. Not to mention, that you - by definition - can't compare apples with pies. refterm is not a terminal and thus cannot be compared with a terminal WRT speed. It simply prove a point on rendering speed, at a cost of breaking a lot of the rules a terminal emulator has to obey to. Most notably is `DECAWM` (DEC Auto-Wrap Mode) that was not properly implemented. The author once stated in a Twitch stream that he simply didn't understand that and thus skipped that part. However, that is the part where it will get complex (and thus slow) if you want to get it right for non-trivial US-ASCII characters, such as complex grapheme clusters (family Emoji most interestingly) or even VS16 (variation selector changing the width of the base code point from narrow to wide). The latter point isn't standardized by DEC anyways, but the younger terminals all try to make the terminal more appealing to the younger Unicode crowd that do expect complex Unicode to render "just fine" (or "as fine as it gets"). refterm also had a hard coded 4k line length limit and just hard-cut off there instead of properly counting for the wrap.
TL;DR refterm (while positively inspirational to a few) was harmful to the terminal community, because it was fooling a lot of people with false metrics that the users simply believed in, without questioning.
> 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.
It would be nice if someone worked on actually improving the terminal experience. Selecting, copying and pasting text is still pretty awful (why is the cursor an entire block rather than a I bar?). Editing multiline inputs is awful. Navigating history is so-so (even with McFly etc.). Anything more complicated than left/right/up/down fails half the time and dumps control characters instead.
Why are terminals always stuck in the 70s? Can I get a modern terminal?
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.
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 ;)
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.
You're doing the classic thing of explaining why things are bad and thinking that that is the end of the story.
> The terminal just takes commands from the host and does what it is told.
> 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 histor
I know!!!
My point was why is nobody working on fixing these issues?
The answer is not because it can't be done. That just shows lack of imagination.
> You're doing the classic thing of explaining why things are bad and thinking that that is the end of the story.
If it was the end of the story, progress would stop. Saying we need a better terminal and then talking about things that run using a terminal ui, but are not the terminal really is the issue here.
> My point was why is nobody working on fixing these issues?
People are working on the problem. There are tons of shells, TUIs, command parsers, web interfaces for commands and interactive apps, some software even work in TUI and GUI mode.
Perhaps a better terminal would help, but I suspect that the problem is there's not really a medium between "better terminal" and "web browser" that won't just evolve into a web browser or something like X over time.
> The answer is not because it can't be done.
No one said it can't be done. You can argue it has been done many times... X11, the web, etc.. But I think the OP was confused about what a terminal is and what the software that runs in the terminal does.
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.
I would love it if it became standard practice for projects to list their dependencies.
I was going to try this but it wanted to pull in Catch2 (some unit testing framework) and apparently has a dependency on Qt.
It is good and nice if your project has unit tests, and by all means use a framework if you think you need one. But don't make me install your framework just so I can do a standard release build. Only require it for building and performing the unit tests.
If the home page mentioned the Qt dependency, I wouldn't have downloaded the source code.
I'm not trying to annoy, I swear. I am using Alacritty for a few years. With tmux config that is moving with me for +- 8 years, except for speed of a terminal emulator, I can't understand the difference between them (other than iTerm2 which is nice but has way too many features)
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)
Your terminal emulator is one of the most security sensitive things you use. Sudo password? SSH keys? logs? A lot goes through your terminal, so I think about 5 times before trying out new terminals.
The major reason I switched from iTerm to Alicritty is the config. I use cmd as my tmux key. This was really annoying to get working in iTerm and was brittle. It required all of macos overrides, iTerms overrides, Tmux config, and Karabiner Elements to get it how I liked it. With Alacritty, it's all done with a clean Alacritty config and a couple of macos-level overrides (I use cmd-q and cmd-h differently in Terminal). Also, the vim+tmux combo is noticeably faster in Alacritty. I'm very interested in Contour.
> The major reason I switched from iTerm to Alacritty is the config.
Exactly the same for me! My terminal config *must* be in version control. But iTerm2 keeps it in some sort of Apple Plist crap. It has a "dynamic JSON profile" feature but it's hard to use correctly.
Switching to Alacritty from iTerm2 has been fantastic; I don't miss anything. I don't use tabs; I use tmux. I need an OS-wide "hotkey" but a few lines of hammerspoon seem to do that perfectly.
It depends what kinds of things you find compelling but I would guess probably nothing if you haven't already been sucked into the terminal emulator rabbit hole. iTerm2 and gnome terminal are both perfectly functional for 100% of the tasks you will actually need them for.
Good point. I share my shell config between Linux and macOS so my UX is mostly the same. Gnome-terminal and iTerm2 act similarly enough that it doesn't really bother me moving between the two.
alacritty's configurability is incredibly good, also the scrolling and crispness in rendering is a godsend, particularly if you're a heavy user or even just do long tails.
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.
> 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.
I’m also in the “I’ve never wished my terminal were faster” camp. Certainly I’ve wished the things I run in it were faster, but that’s a different story.
I split my time between macOS and ChromeOS, and I find it easier to just stick to what’s built in. The things that add friction to my development experience are not waiting for tty characters to draw, they are hopping around between the mess of tabs and windows between the browser, VS Code, and terminal sessions, all tied for a distant third; in second place, waiting for builds; and by far and away #1, trying to understand how this goddamn maze of abstraction and indirection and microservices and frameworks works so I can figure out where to actually put my code.
> I’m also in the “I’ve never wished my terminal were faster” camp.
In the long long ago, I remember having to limit my terminal scrollback to avoid things getting laggy. That hasn’t been the case for a long time, because terminals started taking performance seriously.
So I think advertising speed is more of a table stakes situation than a competitive advantage. I want to see that a new terminal emulator is thinking about speed because if they’re not, I can probably rule them out as an option immediately.
I hadn’t had this issue for years, about 4 months ago I started at a new company which had a big rails monolith. I’m now super conscious of ever resizing iterm, if I leave a terminal running for more than a day resizing the terminal brings the entire laptop to its knees.
Modal? The various input modes. Think of them as if you're using vi/vim, except that it's a terminal. Insert mode is just like every other terminal. Press Ctrl+Shift+Space to move to normal mode (configurable) and use many of the vim motions you know to navigate through your history. The supported keys go way beyond what Termite and Alacritty implement. You might find that you'll never need a mouse again (or almost never). For anything that's missing, please file a ticket, and we're going to work on that.
> Certainly I’ve wished the things I run in it were faster, but that’s a different story.
I absolutely agree. Most of the performance metrics that people talk about is beyond visual perception anyways. In Contour we've only done some optimizations the way we did it because it was actually fun to implement, and a nice little challenge.
While I myself feel like i'm pretty much hard-lining into the terminal, I accept that some things are better left to the GUI world, e.g. daily web-browsing I should not be forced to use w3m or the likes. :)
> I’m also in the “I’ve never wished my terminal were faster” camp.
I have an application that I run daily that is noticeably (15-20%) faster if I redirect terminal output to a file, or if I use a non-default terminal emulator. In this day and age, not being able to keep up with drawing 80 x 24 even with unicode is just not acceptable.
Hey, we are using Qt only on the pure frontend GUI side. The rendering itself is using FreeType + HarfBuzz independantly of the GUI.
We chose this model explicitly to still be free to replace Qt with something else in the future - iff we have to.
The reason behind that decision is, that we actually started with GLFW3, and epically failed, because GLFW3's input model was inferior and the API that I needed was actually marked deprecated by the GLFW3 devs and they also stated that their input model is not good and needs a rework. That led me to the decision to look around and find something else.
I only wanted to keep the GUI framework dependency as minimal as possible.
We sadly do not have BiDi support just yet, I'd actually love to have that. So far I only know of 2 terminals capable of this: mlterm and gnome-terminal.
Unfortunatily I lag the skills of hacking this in except doing it naively. I'd be more than happy for external contributors knowledgable enough in the domain of BiDi, to help us out here. :)
Not that commenter, but I also use mlterm and have for years, even though I don't normally use BIDI or other ‘exotic’ language capabilities. It is just a terminal, in the do-one-thing-well sense. Its downside is its somewhat idiosyncratic configuration (although there is now a GUI for most of it, so newer users might not notice).
This doesn't make sense. WebGL is as GPU accelerated as the other young'ish GPU accelerated terminals, except that they're not running in the browser, which should(tm) make them run faster.
On the other hand, rendering is just one thing to benchmark, there is input latency (already mentioned in this thread here somewhere), but also (terminal / PTY) bandwidth throughput. This is three categories where 2 of the 3 are not related to "GPU acceleration" at all. :)
Sorry for being that HN commenter but, if not, I'm bored with yet another terminal that just equates established features.
iTerm's killer feature is `tmux -CC` support, so that tmux's sessions are integrated natively. I find it shocking that, years after tmux established this feature, iTerm remains the only terminal emulator to use it.
Tmux control mode is one of the keys reasons I can't leave Mac. I also feel it's unbelievable that iTerm 2 is still the only terminal that supports this feature.
For anyone who is asking why this feature is good: it's really not that easy to see the benefits from the documentation, blog or even videos, until you personally try it. At least that's the case for me.
I worked on a pull request to implement it in Terminator a long time ago, but eventually gave up. Control mode was contributed to tmux by the author of iTerm2, and if you explore the iTerm2 codebase you can definitely see that they're very tied together in terms of implementation choices and general design. It's not that simple.
In order to have two-way synchronization, your terminal needs to not only have an architecture where you can add a background thread that can control the "main" terminal interface, but also be flexible enough to properly size all windows and panes, and match font sizing. If your terminal supports different font sizes for every pane/split, those have to be turned off in tmux mode. There's all kinds of corner cases.
And then the normal feature of tmux is that it persists across ssh sessions. This also means that the entire iTerm2 window and all its tabs and splits are also maintained across sessions. I think my current layout on my main development machine that I remote into is over 3 months old.
Another point of view is that it decouples the state of your tmux tabs/panes from your terminal emulator itself. e.g. if you use this locally instead you could then terminate the entire iterm program and reopen it and restore the same exact window/tab/pane splits you previously had. This is a nice perk for restarting/updating iTerm.
> f you use this locally instead you could then terminate the entire iterm program and reopen it and restore the same exact window/tab/pane splits you previously had. This is a nice perk for restarting/updating iTerm.
iTerm seems to be able to pull this off itself during upgrades, even without tmux. The first time it happened, I was surprised, and now I just install iTerm updates with abandon, knowing that all my 40 terminal windows and all the stuff in them will come back after the update.
I appreciate your explanation, but I'll confess that I still don't get it. I assume I'm just not understanding; please don't take offense.
The state of my splits etc are already distinct from the terminal emulator as is/are the session(s) without CC. I can restart my terminal emulator or add new sessions at will without needing any special support from the terminal.
First, some background: Tmux is great but (like GNU Screen) introduces a layer of abstraction between you and the shell. You have to use its special keybindings to create new windows, switch window/pane, or most annoyingly to scroll through history.
Control Mode removes that layer of abstraction, so (with iTerm) you can use all the normal terminal emulator functions to do what you expect: click on panes to select them, tmux windows are just native tabs, and you can scroll the terminal natively
In effect, all the UI compromises you had to do to make use of tmux... go away.
It’s a huge benefit, because it means all the friction of using tmux disappears. Instead of thinking “do i really want to deal with tmux’s UX for this quick ssh session?” (it’s never as quick as you think) I just do it. All my terminal sessions are now in tmux. If I’m doing something on a remote machine, i can confidently close my laptop and know i can restore later.
the iterm mode allows one to create, split, resize remote terminals as of they were native terminal windows, instead of all of them being contained within one terminal window and controlled using completely different keyboard-only shortcuts (via tmux)
Mainly the native feel. For example, you can use standard Cmd-based keybindings to control tabs and panes, and get smooth mouse scrolling in each pane.
How is it useful? I could never understand why I would want something like that as opposed to just using Tmux splits & terminal emulator windows. And this is the only selling point of iTerm! Everything else is strictly worse (lag, CPU/memory usage) compared to plenty of emulators.
Does anybody know if it's actually fast in terms of low latency? I personally don't care about GPU acceleration or any of those things that Alacritty and others claim makes them fast when the latency is noticeably worse than older non accelerated emulators.
Many interpreters don’t use Readline (e.g. IPython and Zsh), and enabling inconsistent Vi keybinsings in each one can be a bit annoying. From that perspective, adding it to the terminal seems a possibly easier way to get it “everywhere”?
Possibly more universal, but there are also tools like rlwrap [1] that adds readline support to programs that don't have it. From the docs apparently the readline library ships a similar tool ootb nowadays but I haven't tried that and just noticed now when I wanted to share the rlwrap link.
To be fair, the vi input mode (or modal input modes) in Contour are way more than simply doing `set -o vi` in bash. You cannot compare those two.
The reason why I implemented modal input modes (vi mode) in Contour is, that I noticed Tilix [1] is having vi input modes and people seemed to like it, I wonder if it might be useful to me personally as well, especially since I'm a heavy VIM user, I asked myself if it might make sense to have in a terminal. So let's get it in.
I was surprised how much it became part of my daily live, in fact, there's no need to grab the mouse at all when using Contour. You press Ctrl+Shift+Space (configurable) to enter normal mode and move the cursor just like in vim (way beyond the basic support that Alacritty implemented).
Especially paired with the indicator statusline support, when showing this one permanently (you can also change the color of that statusline), it became one of the first-class features for me on why I like Contour (not just because I am developing it).
Fun things to do (especially when shell integration is enabled):
- `yim`: to yank the text in between two markers (that is your command output)
- `%`: jump to matching bracket, good when having cat'ed a long json file and you want to quickly browse around
- you can also rectangular select like in vim, and then press either p (includes LF) or <S-p> which joins the multiline clipboard text into a single line (removing LF's), that payed off a lot for output like `git status` and wanting to operate on parts of the output (files e.g.)
Feels a little bit misleading to say that honestly. It runs on windows in what is effectively a chroot/jail/container esque monstrosity. I personally consider that to qualify as a totally separate userspace and therefore not the same operating system as one would assume when you use the term windows without any additional qualifiers.
I just tried it and I will keep an eye on it for later. Currently it is a work in progress and there is a lot of issues with the dependencies and compatibility with legacy setups, but it is way better than Warp and other GPU terminals that I tried.
I am currently a happy user of Urxvt and intend to continue until I am forced to switch to wayland (in a long time, I hope). In comparaison I have to add that the rendering in more defined in Urxvt that Contour even after tinkering, and like always it uses at least 5 times less memory.
> In comparaison I have to add that the rendering in more defined in Urxvt that Contour even after tinkering,
Nothing is perfect. Many thanks for trying though. If you don't mind, maybe you could file a report in github.com/contour-terminal/contour/issues/ such that we know about it, can track it, and also, report back to you, once it's improved?
Generally speaking, it's hard to say that rendering is that bad, because we simply use FreeType for glyph rasterization as well as Harfbuzz for text shaping. That doesn't mean it's perfect. I know that not everybody likes lcd subpixel rendering in Contour, and that anti-aliasing (AA) methods are generally highly subjective on what the best AA method is. We implement multiple such that most users should find what they like the most.
If that still doesn't fit, I'd like to know about it, so we can hopefully fix it, just in case it is a bug on Contour's end.
> and like always it uses at least 5 times less memory
That's not a good metric to look at, at least it's not enough info to judge about. I recently read a guy comparing the memory resource usage of many terminals when having 2,000,000 lines of history configured and found Contour to be the winner here. This doesn't mean much though. I think just looking at the memory consumption is not enough to reason about it. I do agree however, that it should not blindlingly grow over time to something unreasonable. We try not to carelessly allocate any resource, so I'm pretty certain that we're doing "okay" in terms of RAM requirements.
I will find some time to write an issue about the rendering.
And you're right, contour is doing okay in terms of memory, especially compared with other modern terminals. It's just that the first run after built uses already 250mb, and I think that when I will setup some fonts and run a few panes inside it will probably go higher. But if it stays around this number, it's really fine.
Once in awhile I’ll try these new emulators but I keep going back to iTerm2. Maybe having a comparison of the two or similar would help convince me and others in the same boat.
I've in the camp of never noticed my terminal emulator being slow. Used iTerm2 for 10 years, switched to Alacritty recently for reasons unrelated to performance. Before iTerm2 on Linux I don't really remember what I used but I don't remember it being slow. Haven't noticed scrolling speed being slow, and I don't get this "insert latency" obsession.
Your benchmark is more than 6 years old, on a 2014 Macbook, with a strange choice of terminals. LWN's article on the subject is almost as old, but with a better comparison: https://lwn.net/Articles/751763/ (2018)
It says Terminal.app follows closely behind the fastest. This level of discussion around “fast” terminals is funny to me. I’ve always used Terminal.app and never had a single problem. It turns out the default option is likely the best in this case.
I like that they reference the VT510 manual, if the terminal implements the more advanced control codes then individual applications can do their work without needing to rely on their own implementations of the needed functionality. I'm gonna give Vttest a whirl in Contour and if it does well I'll try daily driving it for a while.
Please give us feedback in the issue tracker. We know we're not perfect, but certainly very much appreciate positive constructive feedback as well as bug reports.
p.s.: I did not submit this link here, I intentionally try to avoid that, but I am surprised by the amount of people talking about terminals generally speaking here in this thread, even though a lot of comments (didn't finish yet) seem to be non-Contour related :)
There are many reasons for me to not have kitty protocol implemented. Objectively speaking, I try to mention only one here: Sixel seems to have raised attraction across the whole terminal community over the past years and gets stronger adoption over other image protocols. Ah, and a second one: Kitty's image protocol is slow, purely performance-wise speaking. As an end-user that simply wants to cat an image, it probably won't be noticable, and our Sixel implementation isn't the fastest on earth either, but I welcome any contribution to Contour.
What nonsense. kitty's graphics protocol is literally infinitely faster than sixels for local transmission and the same speed as sixels for remote transmission, taking into account that kitty's graphics protocol supports 32bit colors, unlike sixel.
This is interesting. I am trying not to feel offended by your toxic play, so let's get started:
> kitty's graphics protocol is literally infinitely faster than sixels for local transmission
Let's get the comparison right here (not apples with pies), Kitty graphics over the PTY wire is slower than Sixel over the PTY wire. Kitty supports bypassing the PTY by just referencing to a file locally present on the file system or using n SHM region on the local memory. Both solutions won't work over the internet, because they break the VT I/O model. But you are right, when bypassing the wire, it'll be faster. That sadly limits you to local-only use.
> literally infinitely faster
I wonder what your math behind this is :-P
> taking into account that kitty's graphics protocol supports 32bit colors, unlike sixel
Sixel is using a palette to define the colors to reference from. This pallete can be either in Hue or in RGB format. Of course, the palette has limited amount of entries (which can be queried), but during the image transmittion, just adjust your palette, to get a breader range of colors to chose from. It's still RGB, or to be more precise RRGGBB (8-bit red/green/blue components, which makes it 24-bit. I wonder if what you mean with 32-bit colors other than 24-bit colors plus 8-bit alpha. Alpha values is something that is not supported by sixel (wrong age for Sixels :D), but still it is possible to render images that do not cover only rectangular parts. For example that image here: https://contour-terminal.org/screenshots/contour-notcurses-n... - look at the logo. But I agree, semi-transarent images are not possible using Sixels. But then, you probably want to use a GUI then :)
No, its only slower over PTY because the kitty protocol is transmitting images with higher fidelity, aka color accuracy. So if you want to compare apples to apples get sixel to transmit images with equal fidelity first. I'll go raise three generations of my family while you try to achieve that.
As for infinitely faster, that was obvious hyperbole. For local transmission, using shared memory to transmit RGBA data directly is going to absolutely crush serializing then transmitting over a pipe the de serializing. This is so obvious it doesnt even need to be stated. And the vast majority of image display and indeed terminal usage in general happens locally not remotely. Which is why the kityt protocol sensibly prioritizes that use case.
How did you install Contour and what is the TERM environment variable set to and is your terminfo properly resolved? I just asked someone with an AMD/NVIDIA card to try out nvtop inside Contour and it worked. So I assume maybe there is something fishy with your TERM/terminfo configuration.
It's easy to install on ArchLinux and Fedora. The build process seems to be just standard CMake, so calling it "borderline impossible" is really a stretch.
If you don't like flatpaks it seems to be available on the AUR, fedora or homebrew if you're using mac. Debian repositories are always lagging behind for new stuff so that's no surprise but the dev provides a script for installing dependencies on the rest of the distributions somewhat customized to your flavor if you're willing to build from source. There is a debian directory so it seems like they started the process of getting included but you'll have to verify in the mailing-lists to see what the current status is.
I'd say that's plenty of options to choose from. The simplest being flatpak. Are you a package maintainer yourself? Do you know how much work is involved to get into the main repositories? This is not npm.
While I personally find your comment quite insulting, I think that we have pretty brought support for various mainstream Linux distributions and also release binaries, including for MacOS and Windows. For Arch there's even an AUR, and for Fedora it can be also officially installed via `dnf`. Everyone else can grab a binary from the release page.
If there is anything else that you find is missing, I am more than curious to hear about it and we'll evaluate the priorities to include it. Other than that, I'm inviting you to contribute. :-)
