Yeah, in an effort to spur adoption, I built (shameless plug) https://www.arewesixelyet.com/. What’s interesting is that if VTE gets support, a lot of other terminals will, since they depend on it.
This is astoundingly great - thank you for linking!
(The expected use case - generating quick plots on a remote machine; I usually just scp them back, but with this, and the new-to-me matplotlib integration, i can just have them show up in the terminal without having to launch a notebook or fight with X). Well supported by iterm2 on mac as the terminal side.
https://st.suckless.org/ used to have a circa st-0.8 fork that supported full color sixel graphics, but it seems that specific patch is not in the official list anymore. [1] I think the work moved to https://github.com/jhhuh.
You can even compose the gnuplots with the scrollback patch to scroll back in your gnuplots. I use this all the time. In fact, I just have GNUTERM="sixelgd enhanced linewidth 3 fontscale 2 size 1600,900 truecolor" in my environment variables.
Combined with shell history (or gnuplot history) this makes for a rudimentary "notebook"-like interface, but with a log instead of a file to record state.
You could also use the techniques of [1] but use `set term png` and `set output "/tmp/pl.png"` instead and then auto-launch any image viewer on "/tmp/pl.png" instead of relying on terminal graphics at all.
Is gnuplot better for the use cases demonstrated on the page here?
I've always avoided gnuplot because it has looked pretty hard to get anything useful out of. But uplot looks much more approachable. Just piping some data to "uplot hist --nbins 20" is something I'll remember.
Within the gnuplot shell you use `<` at the start of a "filename" like
gnuplot> plot '<pipeline'
It just uses system(3) for "pipeline". So, technically you could have a whole script in there with maybe tricky gnuplot-quoting/escaping of shell stuff.
You do have 2 different history logs this way - the shell one and the plot one while the uplot way is integrated.
If you really want integrated, you could drive gnuplot with temp files, though each shell command-line would probably have to pass a lot of controls. E.g.,
#!/bin/sh
cat > /tmp/dat # should use mktemp -d
cat > /tmp/p.gpi <<-EOF
plot '/tmp/dat' $*
EOF
gnuplot /tmp/p.gpi
and then
$ seq 1 10 | gpl with lines
It is an exercise for the reader (well, it has probably been done N times...) to harden the temp paths, clean up afterward, generalize to source user/maybe per-directory `foo.gpi` setup and so on.
In the unlikely event temp space is actually any sort of issue then you might be able to use mkfifo (I've never tried) or else generate a .gpi script that uses the plot '<string' syntax escaping `string`.
Oh, that goes to show you how little I use it. I read the documentation and merely assumed that it would work for stdin, but gnuplot exits with an error in that case. This will work, but it’s pretty funky:
This worked directly in Konsole for me without "xterm -ti 340" and it renders a high res image, which surprised me: I have used low-res images in the terminal using block characters and 24-bit colors before, but never seen this high res
How does it do this?
One weird thing seems to be that it doesn't support zooming in/out the same way the regular text does.
No, for the VT340 they devised a set of escape sequences for encoding bitmaps called Sixels; each character encodes a vertical stripe of six pixels. They used it both for displaying graphics and printing. They also did a vector graphics system called ReGIS a few years earlier.
someone please enlighten me, why can xterm do this cool drawing while the modern gnome-terminal can not, I tested the GPU oriented kitty that can display images in terminal, but it could not run gnuplot as xterm. what're missing?
XTerm implements an old bitmap protocol invented in the 80s. The author of Kitty rightly points out that it’s inefficient, limited to one color per column of 6 pixels (if you want a second color you can go back to the start of the line and print over). Rather than implement support for the Sixel protocol, the author of Kitty choose to implement something modern. It’s actually rather nice; the program can print out a filename for Kitty to load, or even point to a shared memory buffer. Those are very efficient options, provided your program is running on your local machine.
Meanwhile Gnuplot supports a wide variety of “terminals”, many of which are just outputs to files of various types, some of which are GUIs, others of which are for actual terminals, like “dumb” (ordinary printable characters), “tek40” and “xterm” which use a protocol invented for Tektronix terminals, “sixelgd” which uses the sixel protocol from the VT340, half a dozen types of printers, etc.
But nobody has added one for the Kitty protocol, so it doesn’t work there. The downsides of inventing something new I suppose; the existing software doesn’t automatically support it, someone has to go around and add that support.
The second link points to libvte, which is the terminal engine behind gnome-terminal where the actual terminalling happens. The changes to gnome-terminal itself are mostly translations and uninteresting desktop stuff:
It certainly can. Since more than 20 years ago! I remember that in 2003, as a "little kid", I changed my configuration from latin-15 to utf8 and it was already supported.
