[woodruffw]

I'm skeptical of the value of electron-ified applications when fully native alternatives suffice. However, ignoring that, there are a few (pretty severe) problems with this release:

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

[IshKebab]

> I'm skeptical of the value of electron-ified applications when fully native alternatives suffice.

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

[sime2009]

I'm busy exploring some of these ideas in my little project Extraterm https://github.com/sedwards2009/extraterm .

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.

[drvdevd]

Very cool looking project!

[crazedpsyc]

Enlightenment's Terminology[1] supports a few fancy things including image previews, animated cursors (nyancat is a builtin theme...) and local file links. More impressively, it actually works really well, it's native, and it's fast (even hardware-accelerated). With all of that fanciness, it renders text even faster than suckless' st with a GPU.

[1]: https://www.enlightenment.org/about-terminology

[qwertyuiop924]

>How many support images?

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.

[IshKebab]

> No terminal emulator supports that. Because that's not the emulator's responsibility. That's your shell's job.

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!

[TomMarius]

> How is the shell supposed to make a popup when it can only output text? It can't make popup windows.

Not entirely sure, but probably in the same way like other TUI applications, e.g. vim, emacs...

[IshKebab]

Yeah I didn't mean TUI, I meant a GUI popup.

[nulltype]

Why do the terminal emulator and shell need to be different things?

[qwertyuiop924]

Because some of us want to run NetHack.

[drvdevd]

One reason terminal apps haven't moved on much, and one of the major challenges for any piece of software trying to act as a terminal emulator, is the number of escape sequences that must be supported for common emulation modes (e.g. even just vt10x I believe).

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.

[Klathmon]

I really don't think it's all that much "over engineering".

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

[woodruffw]

Unfortunately, "support for most platforms" tends to result in the kind of user experience that I described above. There's something comedic about millions of lines of compiled Chromium failing to handle the Control modifier on Linux.

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.

[Volt]

I'd say a browser introduces a non-negligable cost.

[drvdevd]

Agreed, though this is a situation that should be improved if the industry wants everyone using browsers for everything.

[woodruffw]

I agree, and I'm sure that the stagnancy of the plain old terminal is behind this and other modern takes on terminal emulation.

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.

[Hydraulix989]

An easy way for me to gain an extra hour or two of battery life is by closing every single Electron.js application I have open (Slack, VS Code, Atom, Discord, Upwork, FB Messenger for Desktop, Telegram, to name a few...).

[JonnieCache]

Pretty sure iterm does all those things, except maybe the collapsable output.

[kolme]

> Hyper tries to run `npm prune && npm install --production` on every startup.

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.

[madeofpalk]

Depends whether you already have the dependencies or not I guess - I'm not sure if it ships with a node_modules or not.

FWIW `npm prune` only removes modules from node_modules that aren't specified in package.json. It won't actually remove and declared dependencies.

[paulddraper]

> The .deb package seems to install everything in /opt

Hm, just like another commonly installed package...

    $ ls /opt/google/
    chrome
    chrome-beta
    chrome-unstable

Though it installs executables

    $ 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

[nilved]

Which is exactly what GP mentioned. Although using `/opt` to begin with is an anti-pattern in all cases including Chrome.

[calpaterson]

Seems reasonable to me if it's a third party package that doesn't want to clobber whatever the distro installs. Where else? /srv?

[woodruffw]

/usr/local, traditionally. Since it only exposes one executable anyways, I'd say the chance of clobbering is fairly small (and reversible, since it's a deb).

[mst]

Augh! No no no no no no. Sorry, this is a pet peeve of mine.

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

[paulddraper]

Which is exactly what I mentioned. Are we looking for a disagreement?

[nilved]

Maybe, sorry if I misread your comments!

[baldfat]

I am using the appimage and I don't have these issues.

Ranger.py runs very smooth and vim is fine. I am kind of shocked that there was no delay and I am on a 8 year old dell.