4 ms·

All these features are already possible in modern terminals. 1) True color support 2) Bold and italic fonts 3) Emojis, Ligatures, unicode in general 4) copy/pa

All these features are already possible in modern terminals. 1) True color support 2) Bold and italic fonts 3) Emojis, Ligatures, unicode in general 4) copy/paste across SSH 5) the ability to split windows into tmux like panes and send text/control the different panes 6) The ability to display images in true color with alpha blending These are only a small subset of features modern terminals have. There is absolutely no need for terminal 2 or awful slow terminal implementation based on rendering via a DOM. Many ternminals support all or most of these features, one such: https://github.com/kovidgoyal/kitty https://github.com/kovidgoyal/kitty

Per_Bothner 8y ago
"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 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.
- aumerle 8y ago
  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.
- TeMPOraL 8y ago
  Using HTML capabilities just for rich text seems like a wasted potential to me. Give me interactive charts and nicely formatted tables :).
  - Per_Bothner 8y ago
    Here is article on gnuplot outputting graphs to DomTerm: http://per.bothner.com/blog/2016/gnuplot-in-domterm/ http://per.bothner.com/blog/2016/gnuplot-in-domterm/
    - TeMPOraL 8y ago
      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.
mikekchar 8y ago
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.
shabble 8y ago
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.
- aumerle 8y ago
  Links are already supported in many terminals, see https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda 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.
  - loevborg 8y ago
    Oh my God, how did I not know this? This is extremely useful.
  - Per_Bothner 8y ago

Per_Bothner 8y ago

"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 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.

aumerle 8y ago
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.
TeMPOraL 8y ago
Using HTML capabilities just for rich text seems like a wasted potential to me. Give me interactive charts and nicely formatted tables :).
- Per_Bothner 8y ago
  Here is article on gnuplot outputting graphs to DomTerm: http://per.bothner.com/blog/2016/gnuplot-in-domterm/ http://per.bothner.com/blog/2016/gnuplot-in-domterm/
  - TeMPOraL 8y ago
    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.

mikekchar 8y ago

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.

shabble 8y ago

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.

aumerle 8y ago
Links are already supported in many terminals, see https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda 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.
- loevborg 8y ago
  Oh my God, how did I not know this? This is extremely useful.
- Per_Bothner 8y ago