[aduitsis]

Exactly as you indicate, even in "classic" terminals we have features like unicode support, color, geometry reporting, mouse reporting, window title manipulation, arbitrary cursor movement, etc. All these are in widespread use today. These features could not have been implemented in a real tty, but nowadays I think it makes sense to have them. Maybe some are a little kludge-ish, but are we really arguing about their usefulness?

So why shouldn't we have a couple of extra escape sequences where the terminal could, e.g. draw an arbitrary bitmap? You are right, that would certainly require some sort of standard becoming prevalent, but why would a little extra capability (that doesn't break compatibility) be a bad thing?

[lmm]

Like extending email, there's a a chicken-and-egg problem. What terminal emulator is going to add a command that no program uses? What program is going to use a command that no terminal implements?

By all means implement this thing - I wouldn't be surprised if there were already terminals that did that. But personally I'd be surprised if it caught on. Compatibility matters.

[BruceM]

In my post, I mention that iTerm supports inline images (although only in nightly builds so far). So does Terminology.

xterm actually support Sixel graphics now (although with 16 colors and a configure flag being set). Other terminals also support Sixel graphics, but not all terminal emulators and not the primary ones (Terminal.app, PuTTY, iTerm2, GNOME Terminal, etc).

Sixel and Regis graphics used to be available in actual terminals. I didn't mention Regis graphics in my post, nor did I mention Tektronix graphics, also available in vintage terminals. Both Sixel and Regis graphics were designed by DEC (Digital Equipment Corporation). Sixel was raster-based while Regis was vector-based.

Should we bother with Sixel today? Who knows? But there used to be standards for this sort of thing, but in the actual physical terminals, before we all switched to terminal emulators, most of which stuff with VT100 / VT220 emulation rather than anything too advanced. (Regis was available in the VT240, while Sixel came with the VT340, I think.)

Once the iTerm inline image support is out in an actual release, I have some tools that I'll update to support soon after.

But I have some follow up posts where I'll talk about some of this in-depth. This wasn't a random one-off post that I wrote. :)

[rsync]

"Exactly as you indicate, even in "classic" terminals we have features like unicode support, color, geometry reporting, mouse reporting, window title manipulation, arbitrary cursor movement, etc."

Is that true ? For instance, I am not aware that (for instance) the OSX terminal app does mouse reporting or geometry reporting.

Does default xterm ?

[Crito]

Yes. For instance, Vim necessarily knows how large the terminal it is in is. Vim also supports mouse input, allowing you to click around in different windows and whatnot.

[judk]

In Terminal.app you can use the mouse to move the cursor at the command line. Since at least 10 years.

[lorenzfx]

For a start I think it would be really awesome, if the terminal could display html (+css).

[rsync]

"For a start I think it would be really awesome, if the terminal could display html (+css)."

That's scary. My browser is a very complicated tool that does a lot of complicated things and has a huge attack surface.

OTOH, the terminal is incredibly simple and does almost nothing. That has been a very useful division of labor these past 20 years and I'd like to keep it that way.

[to3m]

This would probably be a good starting point. I've already found it quite useful sometimes to have programs output HTML+images so that the results can be viewed formatted. A terminal that could display that inline would be very handy! I don't really want one window for my text output and one for my HTML formatted output. There are some open questions (support links? do anything with javascript? etc.) but for my purposes just displaying reasonably-formatted graphical HTML output would be a useful improvement.

(Writing HTML files is workable, but a bit annoying to use in practice, because if you don't run the web browser from your program (= more windows) you have to tab over to the web browser and hit F5. And that assumes you're overwriting prior results on each new run, of course, which you might not want to do (= more coding and hassle).)

I suppose it wouldn't even have to be HTML necessarily, but HTML has the advantage of being some kind of standard and many people are familiar with it.

[a3n]

I wouldn't mind it.