Coincidentally, just today my friend was talking about terminal based browser, and I opened w3m, only to discover that it displays images now. I still couldn't figure out how it does that, so thought I might as well just ask here as it seems to be doing something similar here.
The FAQ[0] says it uses xv to display images. My guess would be that w3m generates a borderless X window running xv set to run on top, then manipulates that window to follow the scroll behavior.
It's even sillier than that. It just retrieves the terminal window with XGetInputFocus, and then stomps on top of another client's window, along with a pile of heuristics to prevent drawing on top of tabs, scrollbars, etc.
Yes, that is horrible. But also goddamn awesome. Sure, I'd never think of doing something similar where it was critical, but you've got to admit that is a fairly clever hack.
>>I opened w3m, only to discover that it displays images now.
I distinctly remember Links displaying images back in 2011.
Now that I think of it, at the same time I was also reading pdfs and watching movies on the framebuffer... probably. I had a bit of a situation with my hardware, so I had to spend three months in runlevel 3 on Fedora... 12, I think?
I still don't know what exactly happened back then but I watched the entire ST:TNG in the terminal. X11 wouldn't start, so that's gotta be the framebuffer, right?
Sixel support is slowly making its way out in some terminals --- xterm has support, but it's not compiled in by default, at least not in the version of Debian I've got here. (I've never seen any terminals with Regis support.) It'd be really nice if it would show up soon; there's a number of cool things I want to do with it.
However, xterms have supported TEK 4010 graphics support for years. It works really well --- unfortunately the TEK 4010 was a vector storage scope device, with no video framebuffer; it literally drew lines on a phosphor screen using an electron gun, and so cannot draw in black. It's surprisingly limiting.
I really wish devdraw would get real Plan9 behavior and 9term would gain readline-style interaction such that they would allow us to transition to a rich terminal which can host text and graphics natively. I know there are some hacks like this one or Terminology (Enlightenment project), but those are still hacks. If you've ever used a native Plan9 environment where running a graphical application from within a shell transforms the shell into the graphical application, you know what I mean. It's very natural to lose the distinction. Yes, there are some hacks and closed applications that do some of this, but those cannot be used universally. Sadly plan9port and their devdraw and drawterm create a separate window and do not transform the terminal.
I find it interesting that the screenshot resembles my Emacs session. Personally, I find terminal emulators to be a worse target for PDF viewers than Emacs buffers.
I'll check this when I get back on my Linux machine, but has anyone tried this in Termite (or Gnome Terminal since they use essentially the same terminal library).
Some notes on Tmux's support: https://groups.google.com/forum/#!topic/iterm2-discuss/PJzHw...
Here are some other weird extended escape codes supported by iTerm on Mac, such as notifications and setting clipboard contents: https://www.iterm2.com/documentation-escape-codes.html