Me too, although in the case of terminal apps, they really haven't moved on since the 70s. How many support images? Completion popups? Browsable history? Current directory widget? Collapsible output?
Honestly if it takes some insane over-engineering to get some actual innovation in terminal apps I'm all for it! And when I say "innovation" I mean "obvious features that should have been there decades ago".
This little gif demonstrates what it can do now: https://github.com/sedwards2009/extraterm/raw/master/docs/ed...
Some more demos of its features are here: https://github.com/sedwards2009/extraterm/blob/master/docs/t...
It is still early days for Extraterm although I use it myself daily (mostly on Windows and Linux). It too is built on Electron. It makes it possible to try out ideas relatively quickly and grants access to a megaton of 3rd party libraries and tools.
A lot of them, actually. Sixel is a thing.
>Completion popups? Browsable history?
No terminal emulator supports that. Because that's not the emulator's responsibility. That's your shell's job. Asking for your terminal emulator to support command completion is like asking X Windows to add tab completion to Gedit.
Go grab a copy of fish if you want, though. I've heard a lot of good things about it.
>Current directory widget? Collapsible output?
Those are just hard to implement, and usually not worth the effort. The directory widget is essentially provided by your prompt in many shells anyways.
How is the shell supposed to make a popup when it can only output text? It can't make popup windows.
> Those are just hard to implement
Presumably easier if you're using Electron though!
Not entirely sure, but probably in the same way like other TUI applications, e.g. vim, emacs...
Thus over-engineering has been with us all along, much of it legacy cruft.
It might be worth considering abandoning traditional terminal emulation entirely in favor of something else if more features are desired.
Personally I think remote and virtualized devices (think qxl/spice, remote audio, etc), could use some love. We have the bandwidth to improve on these technologies today.
I mean, if you want images, history, tabs, to support every language under the sun, and support for most platforms, I'd say a browser is a fantastic way to get most of that "for free".
I can't really blame them (Linux, like every nix, does something unique at the tty level that breaks reasonable assumptions), and I'm sure it'll get a lot worse once they try to run their JS bindings over the pty/tty subsystem of something like Solaris.
I personally prefer that the terminal delegate just about everything besides I/O to plugins or extensions, so Hyper is probably out of the picture for me. That being said, my current terminal of choice (urxvt) doesn't do much on that front either. I hope that other terminal emulator projects pay attention to the development here and adopt the best innovations.
Wait, what, really? Wouldn't that leave you without dependencies if you don't have internet connection at the time?
Seems a very dangerous thing to do for many, many reasons.
FWIW `npm prune` only removes modules from node_modules that aren't specified in package.json. It won't actually remove and declared dependencies.
Hm, just like another commonly installed package...
$ ls /opt/google/
chrome
chrome-beta
chrome-unstable
$ ls -l /usr/bin/google-*
/usr/bin/google-chrome -> /etc/alternatives/google-chrome
/usr/bin/google-chrome-beta -> /opt/google/chrome-beta/google-chrome-beta
/usr/bin/google-chrome-stable -> /opt/google/chrome/google-chrome
/usr/bin/google-chrome-unstable -> /opt/google/chrome/google-chrome-unstable/usr/local belongs to the sysadmin (I grit my teeth at FreeBSD's interpretation of this, much though I love the OS otherwise, and prefer NetBSD's addition of a /usr/pkg hierarchy to avoid jamming packages in /usr instead, which is only a bit less aggravating).
/opt exists basically for vendors to have somewhere to put things that they know won't trample on my /usr/local hierarchy.
(I still think they should've installed something in $PATH, mind, but /opt is not at all the wrong answer to my mind.)
* The .deb package seems to install everything in /opt. This seems to be pretty common practice for electron apps and isn't a huge deal, except for the fact that a wrapper executable/link isn't installed anywhere else on the system. As a result, I had to go looking for the install directory and invoke hyper as a fully-qualified path (i.e., /opt/Hyper/hyper).
* Hyper tries to run `npm prune && npm install --production` on every startup, which (naturally) fails when the user doesn't have node (much less npm) installed globally.
* Most control modifiers don't work on Linux at all, making it impossible to work inside of programs like nano, alpine, etc.
* Throughput seems to be an issue. Running `cat /dev/zero` locked the entire application up.
These problems are understandable considering the (often unappreciated) complexity of terminals, but they're also surprising in a 1.0.0 release.