There is already the need for standardization on inline images, as notty uses another approach than iTerm2, which uses another approach than Terminology.
xterm can do inline graphics too, in the form of Sixel for raster graphics and ReGIS for vector graphics. At least those are sort of standard, in that they were used by real terminals and there are real specs for them.
The annoying thing is, even if terminals standardized on one protocol, none of them set $TERM or use terminfo properly. So there's no good way for programs to actually use these features, because you don't know if you're running in a terminal that supports them, or which escape codes to send to make use of them.
> none of them set $TERM or use terminfo properly.
There's a reason for this, and it's because a lot of things assume certain values for $TERM and completely go to shit when it's something else. In addition, who actually sets $TERM is an open question depending on the architecture of the system you are talking to (and the manner in which you logged in).
Beyond that, the architecture of terminfo is a disincentive to creating new terminals, because you have to get terminfo right everywhere. Yes, one could package a terminfo supplement for iTerm2 and distribute it, but it's a serious bummer to have to apt-get/yum/dnf/emerge on every box you handle just because you like a different terminal emulator. But xterm is already there, so the easy path is to identify as xterm and handle xterm and lie occasionally (like with features like these). And that's how it's going to be. Forever. Because machines are now disposable, and now we're handling tens of thousands of them over our careers, and well-manicured terminfo databases on a few machines in the lab are a relic of the old sysadmin lifestyle.
This isn't old-vs-new NIH, to be clear, it's just that what we call a "server" has gradually evolved, and stateful databases like terminfo represent older ways of addressing systems that nobody really feels like maintaining anymore. Terminals are now much smarter than the average VT100, and it's high time for a terminal to identify its capabilities with a new protocol that doesn't require server-side state. But nobody is working on that, to my knowledge, because the "Unix way" creates an even stronger disincentive to evolve the manner in which we think about Unix lest we disrespect the past. (See systemd.)
> Terminals are now much smarter than the average VT100, and it's high time for a terminal to identify its capabilities with a new protocol that doesn't require server-side state. But nobody is working on that, to my knowledge, because the "Unix way" creates an even stronger disincentive to evolve the manner in which we think about Unix lest we disrespect the past.
How would you write a terminal protocol that could support `vim` with a stateless server?
