5 ms·

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

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 :-)

confounded 9y ago
> 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?
Per_Bothner 9y ago
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.
aumerle 9y ago
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 9y 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 9y 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.
taeric 9y ago
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-images-in-eshell-with-iimage-mode?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa https://emacs.stackexchange.com/questions/3432/display-image...
- msla 9y ago
  > 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 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.)
  - taeric 9y ago
    Thanks for the link! My first attempt at finding this by searching failed, so I left out any links of my own.
msla 9y ago
> 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.
bennofs 9y ago
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.

confounded 9y ago

> 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?

Per_Bothner 9y ago

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.

aumerle 9y ago

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 9y 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 9y 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.

taeric 9y ago

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-images-in-eshell-with-iimage-mode?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa https://emacs.stackexchange.com/questions/3432/display-image...

msla 9y ago
> 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 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.)
- taeric 9y ago
  Thanks for the link! My first attempt at finding this by searching failed, so I left out any links of my own.

msla 9y ago

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

bennofs 9y ago

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.