Our great sponsors
-
sixel-tmux
sixel-tmux is a fork of tmux, with just one goal: having the most reliable support of graphics
-
termite
Discontinued Termite is obsoleted by Alacritty. Termite was a keyboard-centric VTE-based terminal, aimed at use within a window manager with tiling and/or tabbing support.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
Windows Terminal
The new Windows Terminal and the original Windows console host, all in the same place!
-
-
xserver-SIXEL
A X server implementation for SIXEL-featured terminals, based on @pelya's Xsdl kdrive server(https://github.com/pelya/xserver-xsdl)
-
libsixel
A C language SIXEL encoder/decoder implementation, forked from saitoha/libsixel after @saitoha vanished. Receives security patches, accepts PR's filed preferably here but also at saitoha/libsixel. (by libsixel)
-
-
libsixel
A SIXEL encoder/decoder implementation derived from kmiya's sixel (https://github.com/saitoha/sixel).
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
> Thanks for being understanding.
No problem. I know maintaining forks isn't an ideal thing to do and support should ideally land upstream.
> I believe it's unfair that Linux users have fewer options than us Windows users, due to some people thinking sixel is "uncool".
I think the README page of termite pretty much sums up why getting involved in VTE, or any GNOME project for that matter, is a bad decision.
https://github.com/thestinger/termite/blob/master/README.rst...
I'm just a random spectator but perhaps your efforts might've been better spent on an independent terminal project (like Alacritty, for example) rather than trying to get features merged upstream in a GNOME project.
> However, the situation seems to be changing: check the discussion in: https://github.com/csdvrx/sixel-tmux/pull/1 and you'll see there may be some light at the end of the tunnel!
Yeah, I read the entire conversation and if sixel support lands in tmux upstream, it would indeed be good news.
> Thanks for being understanding.
No problem. I know maintaining forks isn't an ideal thing to do and support should ideally land upstream.
> I believe it's unfair that Linux users have fewer options than us Windows users, due to some people thinking sixel is "uncool".
I think the README page of termite pretty much sums up why getting involved in VTE, or any GNOME project for that matter, is a bad decision.
https://github.com/thestinger/termite/blob/master/README.rst...
I'm just a random spectator but perhaps your efforts might've been better spent on an independent terminal project (like Alacritty, for example) rather than trying to get features merged upstream in a GNOME project.
> However, the situation seems to be changing: check the discussion in: https://github.com/csdvrx/sixel-tmux/pull/1 and you'll see there may be some light at the end of the tunnel!
Yeah, I read the entire conversation and if sixel support lands in tmux upstream, it would indeed be good news.
Apologies for misgendering you. My opinion that you come off like a windows fangirl was mostly due to the other rant you linked in the sixel-tmux rant: https://github.com/csdvrx/cutexterm#wait-i-thought-people-sa...
Here you mention some other things unrelated to terminals, and I was mostly addressing those. It seems to me you want a specific type of experience on Linux, but you can't get that, so therefore dismiss the merits of Linux. I think a lot of your impressions on Linux come from using an X11 based setup instead of Wayland. Completely different beasts, and I think a lot of your grievances would be solved by the latter.
For me, I cannot go back to Windows, ethical reasons aside: Sway on Wayland is perfect for me, and it's what I want out of my computing experience.
I actually agree with a lot that is written in those rants, particularly the VTE and gnome terminal situation. It's just your comments on windows vs linux came across as very personal imo, so I suppose I have retorted here with also a somewhat personal rant.
Also, I don't think either platform has many good terminal choices. Besides mintty, I don't think there are that many good (platform exclusive) terminal emulators on Windows. And on Linux, Foot is one of the few that meets my criteria, including top tier Sixel support (though Wezterm meets my criteria too if it wasn't so slow, hopefully it gets faster). But, for example, I could never really like mintty if I was forced to use Windows, because it lacks features I want.
What I'm trying to say: different needs, different use cases, different tastes. Sorry that my original rant came off so negatively to you and that I wasn't able to convey this point I was trying to make.
> unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better).
That's not due to sixels. Check out the sixel nyan cat: https://github.com/hackerb9/sixvid
Look at the FPS indicator in the bottom. It was pointed to me in https://github.com/microsoft/Terminal/issues/448#issuecommen...
The issue may be in your code.
I think I have similar performance issues, as the glyph selection process could be more optimized.
Derasterized is mostly Jart work (who is best known here for her work on Cosmopolitan), we were mostly interested in quality.
Reducing the set of glyph to something that could benefit from optimizations could help.
> I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as ncurses)
Sixel performance is quite decent: personally, I can play videos in my terminal.
Try MPV on mintty: https://github.com/mpv-player/mpv/issues/2183
I have also played with a X server rendering over sixel, no performance issue: https://github.com/saitoha/xserver-SIXEL
When sixel support is added to Windows Terminal, I may update it, because it would be fun to have one tab to run stuff!
> Am I reading this incorrectly?
Yes
> It seems I was wrong, it supports 8-bit color, not 6-bit color.
Good.
A positive first step is knowing when to admit error.
> But that's still terrible, and every Sixel implementation I've ever used has spit out dithered images
OMG, I spoke too fast, there you go again!
I've given you a step-by-step guide to try the best terminal there is.
> So again, please help out with fixing this for me if you know how.
I HAVE TOLD YOU AT LEAST 4 TIMES: YOU NEED TO USE A STATE OF THE ART TERMINAL TO FIRST CORRECT YOUR MISCONCEPTIONS.
Then if you are speaking in good faith, we will talk again.
> Because so far you have not adequately explained what is going on here, or corrected any misconceptions, or helped to fix anything
I'm at a loss. I can't hold your hand while you install msys2 so you realize yourself you were wrong, just like you did with the 24 bit colors which you wrongly assumed to not be supported by sixels.
Let's try a Bayesian approach: considering you have been proved wrong, you should update your priors and consider the likelihood of being wrong again is greater than me being wrong, since I have 1) quite an experience with sixels 2) so far I've been proven right.
> I suspect will prevent you from correctly implementing them in tmux (see here: https://gitlab.com/gnachman/iterm2/-/issues/3898)
You are pointing me to a 6 years old bug report about tmux eating sequences important to display sixels, which funny enough is the original concept behind sixel-tmux: click on my profile and you will notice "Show HN: Sixel-tmux, display graphics because it does not eat escape sequences" by csdvrx on Nov 27, 2019
I agree it was a serious issue, enough to motivate me. I didn't know it was also affecting iterm. At least I learned something too from this exchange, thanks a lot!
> So all paths point towards needing to make some new protocol for this. You may be in the best position to do that too.
All path point toward you mixing up terminal issues and sixel issues, not using the right tool, refusing to even try to use the right tool.
But yes, a few of us are in a position to push for better standards. I think @christianparpar and @hpa have the deepest understanding of the alternative standards. Eventually a few standard may emerge... or not. It doesn't matter. BMP, GIF, PNG and JPG can all coexist, each have their pros and cons. There's no need to make a choice when all apps support loading and saving in the user favorites formats.
> I'm not going to dual boot Windows or use a VM just to use a terminal emulator for a couple minutes, sorry.
Then I'm not going to try to explain you what you are understanding in a wrong way, as only seeing how mintty handle sixels WITH YOUR OWN EYES may correct your misconceptions at this point.
> If you could just explain what that terminal does that's special so that it could be implemented in other terminals, or show a video, that would help.
Click on the url and you'll see a few demos, including the snake.six displayed in a wonderful example of 24 bit "truecolor" support.
Your request to add a video showing how mintty handle font changes seems resonable. It will make a nice addition to sixel-testsuite.
> If GIMP was attempting to pressure other projects to output BMP files then yes, that would be a problem
If other projects did not even support BMP, but only knew about drawing ASCII art with a 8 colors palette, yes, refusing to implement BMP in 24 bit mode as a first step, while spending 6 years debating the best way to achieve the perfect format that will have absolutely no drawback (chasing a wild goose) would indeed be a problem...
I tinkered a bit with sixel support for my "C64 emulator in the terminal" (https://github.com/floooh/docker-c64), but unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better).
Here's the (abandondend) sixel-version source code, only with two colors, more color planes would drastically reduce the performance.
https://github.com/floooh/chips-test/blob/master/examples/as...
I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as curses). This would allow a lot of fun "terminal applications" (e.g. everything that used to run in VGA Mode 13h).
I tinkered a bit with sixel support for my "C64 emulator in the terminal" (https://github.com/floooh/docker-c64), but unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better).
Here's the (abandondend) sixel-version source code, only with two colors, more color planes would drastically reduce the performance.
https://github.com/floooh/chips-test/blob/master/examples/as...
I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as curses). This would allow a lot of fun "terminal applications" (e.g. everything that used to run in VGA Mode 13h).
The issue with Kitty is that its graphics protocol is not widespread yet, so some of the CLI/terminal programs OP uses that can do graphics output may only support sixel. But yea, personally looking forward to Foot terminal implementing one of the fancier graphics protocols, even if it feels more like a toy at the moment (until they are used more). But seriously running the notcurses[0] graphics test with a terminal supporting the kitty graphics protocol is sex, just like the program itself says.
[0] https://github.com/dankamongmen/notcurses
> unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better).
That's not due to sixels. Check out the sixel nyan cat: https://github.com/hackerb9/sixvid
Look at the FPS indicator in the bottom. It was pointed to me in https://github.com/microsoft/Terminal/issues/448#issuecommen...
The issue may be in your code.
I think I have similar performance issues, as the glyph selection process could be more optimized.
Derasterized is mostly Jart work (who is best known here for her work on Cosmopolitan), we were mostly interested in quality.
Reducing the set of glyph to something that could benefit from optimizations could help.
> I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as ncurses)
Sixel performance is quite decent: personally, I can play videos in my terminal.
Try MPV on mintty: https://github.com/mpv-player/mpv/issues/2183
I have also played with a X server rendering over sixel, no performance issue: https://github.com/saitoha/xserver-SIXEL
When sixel support is added to Windows Terminal, I may update it, because it would be fun to have one tab to run stuff!
> unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better).
That's not due to sixels. Check out the sixel nyan cat: https://github.com/hackerb9/sixvid
Look at the FPS indicator in the bottom. It was pointed to me in https://github.com/microsoft/Terminal/issues/448#issuecommen...
The issue may be in your code.
I think I have similar performance issues, as the glyph selection process could be more optimized.
Derasterized is mostly Jart work (who is best known here for her work on Cosmopolitan), we were mostly interested in quality.
Reducing the set of glyph to something that could benefit from optimizations could help.
> I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as ncurses)
Sixel performance is quite decent: personally, I can play videos in my terminal.
Try MPV on mintty: https://github.com/mpv-player/mpv/issues/2183
I have also played with a X server rendering over sixel, no performance issue: https://github.com/saitoha/xserver-SIXEL
When sixel support is added to Windows Terminal, I may update it, because it would be fun to have one tab to run stuff!
> unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better).
That's not due to sixels. Check out the sixel nyan cat: https://github.com/hackerb9/sixvid
Look at the FPS indicator in the bottom. It was pointed to me in https://github.com/microsoft/Terminal/issues/448#issuecommen...
The issue may be in your code.
I think I have similar performance issues, as the glyph selection process could be more optimized.
Derasterized is mostly Jart work (who is best known here for her work on Cosmopolitan), we were mostly interested in quality.
Reducing the set of glyph to something that could benefit from optimizations could help.
> I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as ncurses)
Sixel performance is quite decent: personally, I can play videos in my terminal.
Try MPV on mintty: https://github.com/mpv-player/mpv/issues/2183
I have also played with a X server rendering over sixel, no performance issue: https://github.com/saitoha/xserver-SIXEL
When sixel support is added to Windows Terminal, I may update it, because it would be fun to have one tab to run stuff!
> it feels more like a toy at the moment
It's not! Gnuplot in the terminal open many new use cases, such as examining data on remote hosts with scripts without even bothering to scp the data first.
Also, Notebooks in the terminal is wonderful!
Check https://github.com/koppa/matplotlib-sixel
First, stop accusing me of being emotional.
Second, tell me why 24 bits colors is insufficient for drawing into the terminals?
> then we have nothing technical to discuss
I think you may be right there.
> starting with a baseline of a broken format that doesn't work
Look at that https://github.com/hackerb9/sixvid and that https://github.com/libsixel/libsixel and tell me precisely what doesn't work, in your own words.
Although there's no mosh-server, some people actually ported the mosh-client[1] to Windows using C#. This client is currently being used in the popular Fluent Terminal for Windows[2].
[1]: https://github.com/jumptrading/mosh-windows-wrappers
https://vt100.net/docs/vt3xx-gp/chapter14.html#T14-1
Am I reading this incorrectly? It seems I was wrong, it supports 8-bit color, not 6-bit color. But that's still terrible, and every Sixel implementation I've ever used has spit out dithered images. The only terminal that is able to display full color images for me is iTerm, using the iTerm escape sequences, which are different escape sequences from sixel. So again, please help out with fixing this for me if you know how. Because so far you have not adequately explained what is going on here, or corrected any misconceptions, or helped to fix anything that is wrong with these terminals. And even the various libsixel examples seems to show dithering: https://github.com/saitoha/libsixel
If I'm confused then you could be in a great position to help me out, so please explain.
And there are also other problems with the iterm escape sequences that I suspect will prevent you from correctly implementing them in tmux (see here: https://gitlab.com/gnachman/iterm2/-/issues/3898). So all paths point towards needing to make some new protocol for this. You may be in the best position to do that too.
>Intel macs can run Windows natively. You've also got your pick of emulators, from parallels to vmware, if you roll that way.
I'm not going to dual boot Windows or use a VM just to use a terminal emulator for a couple minutes, sorry. If you could just explain what that terminal does that's special so that it could be implemented in other terminals, or show a video, that would help.
>What you've written makes about as much sense as saying a drawing program should stop trying to support BMP format since it will have to be replaced down the line by JPG or PNG. gimp, paint and others support many formats. Nobody is complaining. People just click on open. They don't care about the underlying formats.
If GIMP was attempting to pressure other projects to output BMP files then yes, that would be a problem. I suspect other projects wouldn't go for that.
> Some people like it bold, some people like the color to be intensified instead when using `SGR 1` (which is responsible for making font intensified/bold).
Indeed, and the right solution is a config options, just as was done in Windows Terminal, since nobody is wrong: it's just a matter of preferences!
The right technical way of handling preferences is offering more choices to the users, with some sane default that will satisfy most users.
Personally, I love italics (I use vim and I want comments shown in italics, and I make an heavy use of bold+italics, cf https://github.com/csdvrx/indent-rainbow/blob/main/after/syn... ) but I would not want to force this option to people who don't want italics, for their own reasons that are none of my business (actually, if they reasons are good enough, it may cause me to change the default choices, but I would never remove the user freedom to make such choices in the first place)
IMHO that's the key difference between MacOS/iOS/Gnome/new school linux on one side (fewer freedoms) and Windows/KDE/old school Linux (more freedoms)