Contour: Modern and fast terminal emulator
github.com
github.com
Personally I'd never use something VC backed for something so critical to my productivity.
With that said does anyone know which open source projects are looking at LLM integration. It’s not a bad idea.
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.
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].
[1] https://tiswww.cwru.edu/php/chet/readline/rluserman.html#Bin...
[2] https://susam.net/blog/from-xon-xoff-to-forward-incremental-...
[3] https://sw.kovidgoyal.net/kitty/keyboard-protocol/
Switched from iTerm 2 like a year ago.
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.
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 know, the task manager is good enough usually but not for having an overall view of everything, and not really for GPU usage. )
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.
Running btop within tmux using kitty also has color problems, but Alacritty also fails at that.
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".
set -g default-terminal xterm-256color
set-option -sa terminal-overrides ',xterm-kitty:RGB'
set-option -ga terminal-overrides ",xterm*:Tc:smcup@:rmcup@"
set-option -ga terminal-overrides ",screen*:Tc:smcup@:rmcup@"
set-option -ga terminal-overrides ",tmux*:Tc:smcup@:rmcup@"
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?
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.
Happy days.
You can put LocalCommand directive in your ~/.ssh/config to scp something to the remote machine. I use it to have my .vimrc synced on all my systems.
You likely need all of them ;-)
IIRC it "fixes" terminfo stuff "within tmux" for kitty regardless of what $TERM is set. Mind you, I was using the latest tmux at that time. tmux 3.2?
Here's the issue I had: https://github.com/kovidgoyal/kitty/issues/3018
Looks like it should be fixed on a very recent tmux; otherwise this MIGHT help:
set-option -as terminal-features ',xterm-kitty:RGB'
Thanks!
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.
What in the actual hell.
Oh my god Fig too! Which of you is encouraging this crap??
I was this has gone too far—hell no.
Been a happy WezTerm for the past year or so.
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.
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 ;)
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.
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.
Indeed. It still has the best feature set of all the terminal emulators I tried, though, and I wish it worked on Linux.
iTerm2 is slow? Man I guess I'm not a heavy command line user. I mosty open 5 or 6 tabs. tmux? Very very rarely.
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.
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)
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
Casey Muratori demonstrated this with his refterm project. It seems like a lot of interest in making fast terminals has followed from that.
This isn't rhetorical. I can't answer the question
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.
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.
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.
xfce4-terminal does just fine for this. So I just use that.
Why are terminals always stuck in the 70s? Can I get a modern terminal?
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.
> 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.
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.
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.
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 ;)
Prerequisites:
./scripts/install-deps.sh
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 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.
What's a compelling reason to switch terminals? Or maybe: is there a compelling reason not to switch?
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.
I use i3.
Trivial to learn and just works.
Xmonad is much, much more difficult.
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.
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)
Gotcha. I'm using tmux sessions for that.
I know it's nitpicky, but it's "macOS" since 2016, i.e. it stopped being "OS X" or "OSX" about 7 years ago.
I'm not interested in tmux since I work on my computer directly.
Is there anything with a comparable feature set that's faster?
I couldn't care less about Mac or Windows support.
What, or in which circumstances exactly do you feel your terminal emulator is slow and would need to be faster?
You might like to try kitty.
https://wezfurlong.org/wezterm/config/lua/config/background....
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.
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 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.
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. :)
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. :)
> Requirements: CPU: x86-64 AMD or Intel with AES-NI instruction set or ARMv8 with crypto extensions.
Edit: maybe https://en.wikipedia.org/wiki/AES_instruction_set#Intel
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.
iterm window->iterm tab->ssh->tmux windows->tmux panes
With `tmux -CC` it lets you hoist that chain upwards and map the entire ssh session into an iterm window.
iterm window (ssh session) -> iterm tabs (tmux windows)
The biggest benefit for me is that you can then open another tmux session within the CC one and use tmux as normal
iterm window (ssh session) -> iterm tabs (tmux windows) -> tmux2 windows -> tmux2 panes
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.
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.
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.
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.
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.
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.
EDIT: Here’s an official source: https://ipython.readthedocs.io/en/stable/whatsnew/version5.h...
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.)
Have a look at the still young website's documentation here: https://contour-terminal.org/input-modes/#supported-text-obj...
for a more complete look of what you can do with the keyboard (normal mode) :)
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.
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.
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.
https://danluu.com/term-latency/
TL;DR; terminal.app on macOS is typically the fastest.
For a recent take, though by one of the competitors, see https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty
> TL;DR; terminal.app on macOS is typically the fastest.
Even on macOS, that's probably not true, at least nowadays. See https://www.lkhrs.com/blog/2022/07/terminal-latency/ (2022)
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 :)
This apparently does not support the Kitty graphics protocol, just Sixel, which makes it look fairly unattractive to me, personally.
> 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 :)
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.
and yet, borderline impossible to install without using flatpak
So which is it ? fast or needs flatpak ?
Are they mutually exclusive?
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.
I can't say I've ever noticed a difference, but everything I use has an NVMe. Perhaps it matters.
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. :-)