"Rendering via DOM" enables rich text via HTML which is much more (and nicer) than "bold and italic fonts" and "images". For example look at the 'domterm help' output in the right upper pane in http://domterm.org/images/domterm-panes-1.png - it is not true than many terminals can display this. (Except of course in the trivial sense of using a library to render to an image and then displaying the image.)

It is also worth pointing out that most of the features you mention (except 1 and maybe 3) use protocols that are not widely supported. DomTerm uses familiar HTML wrapped in a trivial escape sequence. A related benefit is that reflow on window resize works - and you can copy/paste or save as HTML.

"Awful slow" is relative. DomTerm does take some extra seconds if you 'cat' a large file - but if that is your primary measure of a terminal emulator then our needs are very different.

The only difference between "rich text" and what you can do in a terminal is changing font families/sizes. And that is not even close to useful enough to justify runnig a terminal on top of a browser.

As for familiar HTML, it is trivial to write a library that accepts "familiar" HTML and converts it to SGR cdes for formatting. I could do it in an afternoon.

And for "awful slow", do the following experiment. Open a large text file in less in your terminal. Then scroll it continuously and monitor CPU usage (of the terminal and X together). Now compare with a real terminal. Think of all the battery life and all the energy you are sacrificing just for the ability to use multiple font sizes and families.

Using HTML capabilities just for rich text seems like a wasted potential to me. Give me interactive charts and nicely formatted tables :).

Here is article on gnuplot outputting graphs to DomTerm: http://per.bothner.com/blog/2016/gnuplot-in-domterm/

Lovely <3. That's what I'm talking about! The power of rich terminals lies not in cute fontification, but in rich presentations for underlying data.

There are still desirable features that modern terminals struggle with, or provide in an inconsistent way because they all implement it with slightly different hacks.

Some sort of common semantic markup/annotation would be useful to allow terminals to offer intelligent click/hover/select actions on urls, file/pathnames, etc, etc.

This can be done with regex or deeper parsers in the terminal program, but that's slow & fragile. If the outputting program has a way of generating '<a href=...>yourlink</a>' the term can just interpret those and save a lot of trouble.

It means you need a) a common markup standard, b) support from enough terminals, c) support from enough output-producing programs to make it all worthwhile.

You'd probably also want any such markup to be backwards compatible so it didn't horribly mangle content on unsupported terms, unless you could sneak it in through feature detection in termcap/terminfo.

Also, I'm not sure 'rendering via a DOM' is the real point of contention here. My understanding is that there's already a DOM of sorts in most terminals, being used to represent the current window in terms of lines, rows, character cells, etc.

Those cells hold attributes for text colour, formatting, and content, etc.

I don't think it would be entirely impossible/impractical to come up with an enhanced representation along those lines that allowed supporting producers/consumers to do more better things.

A fully-fledged HTML DOM and the bulk of a browser engine required to actually render it is where I think the complication and performance comes in. Not to mention a loss of some of the relative simplicity of display generation that a fixed-size character grid affords producers.

Links are already supported in many terminals, see https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3c... and are actually used by the ls program, ls --hyperlinks

The overhead of an HTML DOM vs the typical cell structure used ina terminal is the difference between Jupiter and Mercury.

Many terminals recognize URLs. DomTerm also recognizes 'FILENAME:LINE:COLUMN:' as in error messages emitted by many compilers. Clicking on such a link opens an editor window at the specified FILE:COLUMN position. The editor is customizable, with buitin suppport for Atom and Emacs. See http://domterm.org/Tips.html#linkification

Neat, I've never seen the link support from there before.

And yes, I wasn't arguing in favour of using a full HTML DOM, but that potentially some simplicity-favouring middle-ground might allow new and interesting features. As you've just demonstrated :P

The overhead of an HTML DOM for terminal text is substantial and unfortunate - but does it matter once you have a few browser tabs displaying typical "modern" web pages?

Oh my God, how did I not know this? This is extremely useful.

Thanks for the link. I'm playing with kitty now. It looks great. It's a little memory hungry, but performance seems really amazing, so I'm probably OK with that.