|
i mostly agree. if you want to run an application that assumes ansi escape sequence support and a terminal emulator that doesn't implement ansi escape sequences, you can run a terminal emulator inside your terminal emulator, with the inner terminal emulator interpreting the ansi escape sequences and talking to the outer terminal emulator with whatever escape codes the outer one uses three options for this inner terminal emulator are gnu screen (previously iscreen, which was a better name), tmux, and emacs term-mode. all three of these can use terminfo to figure out how to manipulate the outer terminal—but they wouldn't have to. mosh also does this terminal-emulator-inception thing but i think it's hardcoded to use ansi escape sequences to draw — ⁂ — what i'd really like to see is a reimagining of the terminal interface as something better than a vt340+. we have lots of historical things that could be sort of described that way (genera's lisp listener, the blit, mgr, caleb winston's stdg, notty, x11, postscript, html, react, wayland, opengl, vulkan, vnc) but they all fall short in one way or another. minimally i want a user interface that i can 1. write programs for in any programming language such that 2. simple programs like 'hello, world' or displaying a two-column table of numbers are about as simple as in an xterm, and 3. the programs' input and output is manipulable by the user at various levels of abstraction (copy/paste, screenshots, editing the output text, automating interactive workflows (like expect/autohotkey/selenium), screen readers, asciinema/screencasting, livestreaming, obs studio), and 4. the program is interactive (html kind of fails at this), and 5. the user interface can be used on a separate computer from the program (maybe the user interface runs on a cellphone while the program runs on a rack in a data center, or maybe the user interface runs on a laptop while the program runs on a quadcopter), and 6. small computers (under a megabyte of ram) can be used to show the program's user interface, but 7. the program can display anything the user's monitor is physically capable of displaying and support any of the user's input devices, including mice, touchscreens, accelerometers, cameras, etc. emulating a vt340+ like xterm does gives you the first six of these, which is a big reason why people keep writing new programs for that platform, but totally flunks the last one; you can't even display text in a proportional font, much less a photo or a video obviously there's some degree of tradeoff in some cases between 5, 6, and 7, because you aren't going to stream 4k video over a 9600-baud serial line, and you aren't going to decode it on a 286 (nor are you going to stream webcam video back from the user if the webcam is plugged into a 286), but there's a pretty broad spectrum today of {comms bandwidth, terminal cpu, desired output} triples for which performance isn't a hard problem—all you have to do is not totally fuck it up like sixel i don't know, i'm not waiting around, i'm gonna be over here hacking on godot instead |
xterm supports sixel graphics.
"sixel" is an image file format; the ImageMagic "convert" command can convert other formats to it. Just cat a sixel file to stdout in an xterm and it's displayed in the window.
The implementation is not 100% solid (for example, there's a size limit), but it does work. And tmux can be build with sixel support, so you can display sixel images in tmux under xterm.
or https://en.wikipedia.org/wiki/SixelNo, there's no video support (unless I've missed something).