Interesting, I will have a look and test it, thanks!
For images to test, on debian I recommend you install libsixel. You can then just use img2sixel to convert a jpg to sixel. Alternatively, install gnuplot-nox and:
export GNUTERM="sixelgd size 1280,720 truecolor font arial 16"
then you can test with various screen resolution and sizes, like:
echo plot sin(x) |gnuplot
Yes, my approach does not solves all problems. It is just a quick and dirty fix to show sixels in the current window because I use gnuplot very intensively on remote hosts. As soon as I switch to another pane, the output is lost. But I use plots mostly to get a quick idea of how things are going, every few minutes or hours.
About https://news.ycombinator.com/item?id=21646398 :
1. yes I do not check for sixel capacity. My approach is that any sequence I do not know about should be left as is, because it may have been made for a good reason, and there will always be newer sequences and terminals I don't know about. For graphics such as sixels, your approach to check for sixel capability might be better as they will need to be redrawn
2. what to do if there are 2 terminals attached is linked to #1. I would by default output the same sequence, because I do not touch what I do not know! If you are checking capabilities, it may be best to show an empty block of the same size at the place where the sixel output would be (a placeholder). Another option would be to use a converter like libcaca to turn the sixel into a rough ascii rendition. It would add a dependency to tmux, but also add a feature for terminals that can't keep up, here because they don't know how to interpret sixel
3. and 4. saving the sixel image is what mlterm does. You could save the .six files in ~/tmux/%PID%WIN%PANE
If you want to be consistent with text lines, you could keep all images until the text line after the sixel image is thrown out of the history.