-
sixel-tmux
sixel-tmux is a fork of tmux, with just one goal: having the most reliable support of graphics
I would point out that sixels[0] exist. There is a nice library, libsixel[1] for working with it, which includes bindings into many languages. If the author of sixel-tmux[2][3] is to be believed[4], the relative lack of adoption is a result of unwillingness on the part of maintainers of some popular open source terminal libraries to implement sixel support.
I can't comment on that directly, but I will say, it's pretty damn cool to see GnuPlot generating output right into one's terminal. lsix[5] is also pretty handy as well.
But yeah, I agree, I'm not a fan of all the work that has gone into "terminal graphics" that are based on unicode. It's a dead-end, as was clear to DEC even back in '87 (and that's setting aside that the VT220[6] had it's own drawing capabilities, though they were more limited). Maybe sixel isn't the best possible way of handling this, but it does have the benefit of 34 years of backwards-compatibility, and with the right software, you can already use it _now_.
0 - https://en.wikipedia.org/wiki/Sixel
1 - https://saitoha.github.io/libsixel/
2 - https://github.com/csdvrx/sixel-tmux
3 - https://news.ycombinator.com/item?id=28756701
4 - https://github.com/csdvrx/sixel-tmux/blob/main/RANTS.md
5 - https://github.com/hackerb9/lsix
6 - https://en.wikipedia.org/wiki/VT220
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
I would point out that sixels[0] exist. There is a nice library, libsixel[1] for working with it, which includes bindings into many languages. If the author of sixel-tmux[2][3] is to be believed[4], the relative lack of adoption is a result of unwillingness on the part of maintainers of some popular open source terminal libraries to implement sixel support.
I can't comment on that directly, but I will say, it's pretty damn cool to see GnuPlot generating output right into one's terminal. lsix[5] is also pretty handy as well.
But yeah, I agree, I'm not a fan of all the work that has gone into "terminal graphics" that are based on unicode. It's a dead-end, as was clear to DEC even back in '87 (and that's setting aside that the VT220[6] had it's own drawing capabilities, though they were more limited). Maybe sixel isn't the best possible way of handling this, but it does have the benefit of 34 years of backwards-compatibility, and with the right software, you can already use it _now_.
0 - https://en.wikipedia.org/wiki/Sixel
1 - https://saitoha.github.io/libsixel/
2 - https://github.com/csdvrx/sixel-tmux
3 - https://news.ycombinator.com/item?id=28756701
4 - https://github.com/csdvrx/sixel-tmux/blob/main/RANTS.md
5 - https://github.com/hackerb9/lsix
6 - https://en.wikipedia.org/wiki/VT220
-
-
Nice! I became obsessed with rendering sparkline representations of chunks of audio for the same reason: to inspect failures when writing tests / refactoring. https://github.com/sudara/melatonin_audio_sparklines
-
> I don’t see why sixels couldn’t work.
Sixels will work: they are fast enough to allow youtube video playback !!!
https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/README.md
But the problem is NOT THE FORMAT, the problem is the lack of tooling. links and w3m are among the rare text browsers that can display images in the console.
It's just a matter of the browser sending the image to something in some format, but if that hasn't be thought about as a possibility (say, for text reflow issues) it's going to be far more complicated than just adding a new format, as you will have to work both on say the text reflow issues (ex: how do you select the size of the placeholder, when expressed in characters?), and the picture display.
Personally, I do not care much about sixels, kitty or iterm format - all I want is to see some kind of support.
Yes, it would be better if that support was for the option that has the greatest chance of succeeding, but even that is a second concern: in the worst case, we can write transcoders to whatever format people prefer!
But when there is no "input" to transcode, you have a much bigger problem!
> an off the shelf ASCII plotting library probably involves less custom tooling
With a terminal like msys2 or xterm, no custom tooling is required: just use the regular gnuplot after doing the export for the desired resolution, font, and font size.
gnuplot is far more standard than plotting library that often require special Unicode fonts on top of requiring you to use their specific format.
-
I was inspired by your work to do a juce implementation: https://github.com/FigBug/Gin/commit/30aa84130f4f607bdeba538...
I think the most useful thing for me is I can call it from lldb and immediately dump buffers to my terminal while debugging.