sixel-gnuplot VS notcurses

A few years ago, you had to recompile it to add sixel support on debian, so I provided https://github.com/csdvrx/sixel-gnuplot

Now it's included by default IIRC

sixel-tmux works literally anywhere you can use tmux: as long you can display unicodes on your terminal, the sixels will be "captured" by sixel-tmux and converted into something you can see. Sixels are in-band, so ssh isn't a problem.

In a way, using sixel-tmux is like "giving magical goggles" to your terminal, to let it render sixels so you can see something (even if it isn't perfect), in the hope you'll be tempted to use a better terminal that will show you sixels in all their glory, with a pixel perfect quality.

Sixels enable all kind of cool things, like gnuplot right in your terminal (cf https://github.com/csdvrx/sixel-gnuplot ): sometimes I even watch youtube on my terminal lol

sixel-tmux was made as a first step towards turning derasterize into a more general library: my plan was to add it to nnn but I got bored along the way and moved to other stuff. I might still do that I I love nnn as a filemanager.

BTW, even if there have been quite a few interesting work by @hpa and others in the last 2 years, I think derasterize still has textmode supremacy. derasterize is a collab with @jart after I started adding features to her previous solutions which was based on half blocks like this solution; she's also made further work based on this like https://justine.lol/printimage.html and https://justine.lol/printvideo.html

That's also my main usecase: doing plots with gnuplot

A few years ago, it wasn't compiled by default in the debian packages so I released binaries: https://github.com/csdvrx/sixel-gnuplot

I wish framebuffer consoles would support sixels to do without X or wayland, mostly to have inline plots line https://github.com/csdvrx/sixel-gnuplot without having to use say fbi

> On the other hand, text output to the console has generally gotten slower, usually much slower than you would expect for the change in console size

I don't see why we should tolerate slow rendering of text. The techniques recently used to accelerate text rendering in Windows Terminal should be usable in the framebuffer console.

and sixel support can be made to work with this: https://github.com/csdvrx/sixel-gnuplot

> The only reason we don't have animation frameworks for the terminal is because it's not possible

https://nick-black.com/dankwiki/index.php/Notcurses

Notcurses. Install it and run notcurses-demo to be suitably impressed.

Same for me, I would be much more motivated if there was something like textual for Rust. Given the capability of terminal emulators now I think Rust is lacking behind in the TUI field. Just checkout what can be done with something like notcurses

On the application side of rendering, see notcurses, it is at the leading edge: https://github.com/dankamongmen/notcurses

Other TUI libraries of note: https://github.com/dankamongmen/notcurses/blob/master/doc/OT...

The broader world probably knows him best for the terminal handling library Notcurses[1] and a lot of telling terminal emulator authors to get their shit together.

I’ve had his grad-school project libtorque[2] (HotPar ’10), an event-handling and scheduling library, on my to-read list for years, but I can’t seem to figure out how it accomplishes the interesting things it does.

[1] https://nick-black.com/dankwiki/index.php/Notcurses, https://github.com/dankamongmen/notcurses/

[2] https://nick-black.com/dankwiki/index.php/Libtorque

In XTerm, this (rightly) makes no difference. In Foot and Contour however, you still end up a line resp. a screen below where you started, if now with the correct horizontal position.

So it seems to me like what you want should work by default, except it doesn’t.

It should be possible to instead just treat the whole thing as a graphical overlay (by computing or directly asking for the character cell size, as Kirill Panov rightly admonishes me is possible with XTWINOPS) without touching the cursor; that’s what the “sixel scrolling” setting (DECSDM) is supposed to do. Then you can just manually move the cursor forward however many positions after you’re done drawing.

Except apparently the DEC manual (the VT330/340 one above) and DEC hardware contradict each other as to which setting of DECSDM (set or reset) corresponds to which scrolling state (enabled or disabled), and XTerm has implemented it according to the manual not the VT3xx[1,2,3]—then most other emulators followed suit[4]—then XTerm switched to following the hardware[5,6] (unless you and that’s what I’m seeing on my machine right now. So now you need to check if you’re on XTerm ≥ 369 or not[7]. If I’m reading the Notcurses code right, other terminals have followed suit[8].

Again, ouch.

P.S. It seems DEC had an internal doc for how their terminals should operate (DEC STD 070) [9]. It does not document DECSDM at all.

[1] https://github.com/wez/wezterm/issues/217#issuecomment-86449...

[2] https://github.com/hackerb9/lsix/issues/41

[3] https://github.com/dankamongmen/notcurses/issues/1782

[4] https://github.com/arakiken/mlterm/pull/23

[5] https://invisible-island.net/xterm/xterm.log.html#xterm_369

[6] https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-T...

[7] https://github.com/dankamongmen/notcurses/commit/0918fa251e2... (the correct version cutoff is 369 not 359, the patch contains a now-fixed bug)

[8] https://github.com/dankamongmen/notcurses/blob/master/src/li... (look for mentions of invertsixel)

[9] http://www.bitsavers.org/pdf/dec/standards/EL-SM070-00_DEC_S...

And there's also the notcurses library: