Wasn't Sixel necromancy primarily done to implement streaming Twitter client for demoing NetBSD running on an obscure 68k based machine at an Open-Source Conference?
seems like the need here is for a graphical terminal. a terminal that displays graphics which are sent to it as graphics, and not as ascii-encoded binary.
the default terminal in plan9 could do this, though i don't know of anything which took advantage of it outside of plan9 itself. you could open a new window (which is a terminal with a prompt and a cursor and a shell and so on), and type the command to launch the window manager ("rio") and it would launch a new window manager inside your terminal window.
it's not even really fair to call plan9 windows "terminals" since they're plan9 windows and anything that can be displayed on plan9 can be displayed in one.
the neater stuff comes when you use one of those plan9 windows to remote into another machine and run a graphical tool inside it. you could run the window manager of the remote machine and display it locally, all through normal commands you used all the time and without any special software, and you could open more plan9 windows inside that window manager inside your local plan9 window inside your local window manager. all over the 9p protocol that plan9 used for everything. 9p is used all over the place today, but only for relatively niche things.
i think we've really ignored a lot of what plan9 did, to our detriment as an industry.
This project is old enough that it uses the plain text README format that was intended to be read from the terminal back before GitHub became the de facto way to read source code.
The interesting thing is that the author has been inactive for long enough that the 2021 fork by someone else has now itself lapsed into inactivity.
* https://news.ycombinator.com/item?id=27447638
* https://github.com/libsixel/libsixel
saitoha/libsixel looks alive and kicking to me
https://github.com/saitoha/libsixel/commits/master/
the x server (OP link) is inactive indeed
That's interesting. Xe probably should close that issue, then. (-:
Also note https://github.com/Kreijstal/libsixel , another fork that sprang up because the author vanished.
Wasn't Sixel necromancy primarily done to implement streaming Twitter client for demoing NetBSD running on an obscure 68k based machine at an Open-Source Conference?
seems like the need here is for a graphical terminal. a terminal that displays graphics which are sent to it as graphics, and not as ascii-encoded binary.
the default terminal in plan9 could do this, though i don't know of anything which took advantage of it outside of plan9 itself. you could open a new window (which is a terminal with a prompt and a cursor and a shell and so on), and type the command to launch the window manager ("rio") and it would launch a new window manager inside your terminal window.
it's not even really fair to call plan9 windows "terminals" since they're plan9 windows and anything that can be displayed on plan9 can be displayed in one.
the neater stuff comes when you use one of those plan9 windows to remote into another machine and run a graphical tool inside it. you could run the window manager of the remote machine and display it locally, all through normal commands you used all the time and without any special software, and you could open more plan9 windows inside that window manager inside your local plan9 window inside your local window manager. all over the 9p protocol that plan9 used for everything. 9p is used all over the place today, but only for relatively niche things.
i think we've really ignored a lot of what plan9 did, to our detriment as an industry.
No screenshot lol.
Actually there is a screenshot, but it is in the libsixel repository, because the README here is just the original Xorg one unaltered.
* https://github.com/saitoha/libsixel#x11-on-sixel-terminals
This project is old enough that it uses the plain text README format that was intended to be read from the terminal back before GitHub became the de facto way to read source code.
Oh. Huh. I'm still doing plain text READMEs. Am I not supposed to?
If you don't have a GIF auto play at the top of your readme how can I trust that the code even compiles? ;)
By verifying that each full line in the readme is exactly 80 characters wide.
De facto != best practice
Or in other word, You do you
0h, I read README.md in the terminal with batcat.
I just cat or vi the files. The point of markdown is that it can still be read in the terminal and without any special tools.
My earlier point was that plain text doesn’t support image inlining. Not that markdown requires a web stack to render.