Comment by mikekchar | Hacker News Reader

Comment by mikekchar | Hacker News Reader

Not to start the whole "I hate Electron" thing again (that conversation has been had -- err over-had ;-) ), but I think it's relevant to both Eshell and DomTerm (such as I understand it): I don't want an interface running in such a massive infrastructure. I use Emacs as my daily editor these days and I still don't want Eshell (I don't want to have Emacs up all the time).

But I think the arguments ring true none-the-less. Our ancient terminals are awful. Colours are basically a hack upon hack. You can't rely on getting text effects working properly. Throwing tmux/screen into the works is almost necessary and as much as I like tmux the complication at the interface between the terminal and tmux is insane. How many times have you used vim or emacs in tmux in a terminal and found that somehow the terminal settings aren't getting through properly? I'm practically an expert in that stuff now (through long hard experience) and sometimes I still run into problems that leave me scratching my head.

We're ripe for something new... but I don't think an application of that kind of girth is going to cut the mustard. Again, I'm super happy that people are tackling this problem and if it works for you, then more power to you. But I think that I'm probably pretty representative of the kind of person that lives in a terminal. I can't see that kind of thing getting popular.

What would be awesome, though, is the generation of a new set of standards. We need "terminal mark 2" that has these kinds of abilities and we need standards that will allow interoperability towards applications running in these terminals. For example, as much as the article asks if we need terminal capabilities like ncurses -- I think we do. But we also need capabilities like being able to spawn panes in a tmux pager (just like a window manager). We need proper history navigation, cut and paste (across and ssh session!), etc, etc. These things need to be environment agnostic so that we can build an ecosystem of tools that will become popular. If people want to live in Emacs, or in Electron, then great. If not, then there are potential options.

I know it's a completely half formed argument, but I hope it resonates with some people :-)

I suspect modern terminals just evolved underneath you and you didn't notice since you were looking for a revolution. Most of what you want, you can have. I actually like eshell because I can "cat someImage.png" and it will literally inline the image for me on the terminal.[1] I don't think this is limited to eshell, either. I just don't know how to do it in other terminals.

To be clear, I think it is enticing to imagine a perfect solution. I just don't think it is fair to ignore all of the work that has happened. Nor do I think it is realistic that something will be able to get past the ridiculous cost of entry at this point. There is a reason eshell isn't a complete shell replacement.

To be direct to your points of things we need, though. I think you'd be surprised at just how well eshell does all of them. The only real limit to how well it works is that piping a lot of commands together is limited due to everything going through a buffer. For those cases, "shell" and then doing whatever I was wanting to do, works like a champ. And if I am really wanting to do some fancy stuff, an org buffer is better anyway.

[1] https://emacs.stackexchange.com/questions/3432/display-image...

> I actually like eshell because I can "cat someImage.png" and it will literally inline the image for me on the terminal.[1] I don't think this is limited to eshell, either. I just don't know how to do it in other terminals.

xterm supports sixels, which do real graphics:

https://github.com/saitoha/libsixel

The img2sixel program does what you want in terms of catting an image to the screen and having it show up correctly.

(Scroll down on that page to get to the per-terminal documentation.)

Thanks for the link! My first attempt at finding this by searching failed, so I left out any links of my own.

FWIW DomTerm doesn't really need Electron. Any embedded browser can work - using 'chrome --app=MAGIC_URL' works pretty well. The main thing Electron is used for are the menubar and a context menu - and those can be simulated with plain JavaScript.

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

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

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.

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.

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

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

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?

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

I understand your point and I as an Emacs user I also considered moving to something less "heavy" quite a few times. But I am not convinced that something like you describe is actually possible to build and at the same time be less massive than existing interfaces.

As a question to think about, what features does Emacs provide that are unused? I think most Emacs users end up using quite a lot of the features, so why do you think it will be possible to create something more lightweight?

Don't get me wrong, I want this to exist. But, it is important to look at existing solutions first. For example, isn't the X11or Wayland spec an implementation of "terminal mark 2"? A window manager is the shell. Perhaps we are just missing the right kind of utilities to make this environment as effectively as a terminal shell?

Another point to consider: are the frameworks massive by themselves? I would argue that the bloat comes mostly from having multiple frameworks. If all apps used the same version of electron then you could have a single electron runtime and then it could be more efficient. Same if all apps agreed on a single Qt or GTK version, or any other framework. If in fact redundancy between multiple frameworks is the problem, then another, new standard will not solve this.

In the end, I want to believe that there's something better, and if you have any examples or arguments to convince me I am eager to hear them.

> We need "terminal mark 2"...

I’ve often thought this. Who would draft such a spec? Would the IEEE still be the right place (thinking back to POSIX), or GNU, or Google?

> You can't rely on getting text effects working properly.

terminfo and ncurses seem to solve this problem, assuming you're not just hard-coding in escape sequences.

Reply on news.ycombinator.com