Hi, author of Upterm here. Ask me anything.
Why did you choose to use Electron? It appears to be universal reviled by developers.
What's your opinion?
Upterm – A terminal emulator and interactive shell based on Electron
101–110 of 127 posts
Re: Upterm – A terminal emulator and interactive shell based on Electron
#102Earlier quoted context omitted.
Not the person you're responding to, but when I tried it early this year Alacritty used more CPU and memory than gnome-terminal, and felt less responsive. It was also somewhat glitchy with my usual tmux+text editor configuration. VTE has been around since at least 2002, and in that time it's received a great deal of attention. While I'm always interested in new terminal emulators, catching up to VTE is going to take…
There was an issue earlier this year caused immense slow down on Linux that is already fixed. You may try it again now.
Indeed? I may try it again. I've also been fairly impressed with kitty (not the MinTTY based kitty, the other one), which also uses the GPU, and is written in Python of all languages.
Re: Upterm – A terminal emulator and interactive shell based on Electron
#103Like pretty much everybody, I can't stand electron. But there's an interesting angle here, which is integrating the thing running in the terminal emulator (the shell) with the terminal itself. What I'd be most interested to see though would be a terminal pushing curses support forward, since I use a lot of curses-based applications.
> But there's an interesting angle here, which is integrating the thing running in the terminal emulator (the shell) with the terminal itself
It sure results in exciting and interesting bugs, if you look at upterm's issue tracker.
Re: Upterm – A terminal emulator and interactive shell based on Electron
#104Earlier quoted context omitted.
This is a great piece of feedback, thank you so much! We do utilize a login shell for executing commands, but we only support Bash and ZSH. So, it's a real Bash. However, there are some complications with environment interpolation and built-in commands; it's a known bug and we're working on it. Unfortunately, I don't see how to allow using custom shells while providing a better command entering experience (i.e. zle o…
Maybe you could support a user-defined auto-completion config like Bash et al do for theirs and IDEs would for custom languages too. With regards to the shell input: I don't know how you are currently detecting the $SHELL prompt (and thus when you can do your auto-completion) but maybe you could allow users to specify hooks for what to watch for to determine the different between the $SHELL and other tools, based on…
It works differently: we just create a new shell session for each command. We create a non-interactive session without reading config files to make it fast and pass it appropriate ENV, which we maintain.
Re: Upterm – A terminal emulator and interactive shell based on Electron
#105How's the performance? GNU yes can produce output at more than 10GB/s. Does it cope well with that? How about lots of output that contains lots of escape sequences?
Not to dismiss concerns about terminal performance, but if you need a terminal to keep up at ten gigabytes per second of data, I question your goals* . How can you seek in that much data? Will you page-up or scroll for hours to find what you need? Past 1GB in the buffer, even iTerm2s search functionality lags out painfully, but . . . so does grep, on a file that big. There are other aspects of terminal performance th…
> Not to dismiss concerns about terminal performance, but if you need a terminal to keep up at ten gigabytes per second of data, I question your goals* .
I don't want OOM killer to murder everything just because I accidentally catted a 1 GB file to stdout rather than another file. Or accidentally catted the .iso rather than the .iso.asc. Nor do I want to wait 5 minutes for the terminal to render it all.
Sure, accidents don't happen every day, but it's a massive inconvenience if it does. It was enough to make me abandon all feature-rich VTE based terminals in favour of rvxt.
Re: Upterm – A terminal emulator and interactive shell based on Electron
#106Earlier quoted context omitted.
Not to dismiss concerns about terminal performance, but if you need a terminal to keep up at ten gigabytes per second of data, I question your goals* . How can you seek in that much data? Will you page-up or scroll for hours to find what you need? Past 1GB in the buffer, even iTerm2s search functionality lags out painfully, but . . . so does grep, on a file that big. There are other aspects of terminal performance th…
> Not to dismiss concerns about terminal performance, but if you need a terminal to keep up at ten gigabytes per second of data, I question your goals* . I don't want OOM killer to murder everything just because I accidentally catted a 1 GB file to stdout rather than another file. Or accidentally catted the .iso rather than the .iso.asc. Nor do I want to wait 5 minutes for the terminal to render it all. Sure, acciden…
Those are good points about stability and memory usage, but I'm not sure what they have to do with performance. I'd be surprised (well, not that surprised, but a little surprised and disappointed) if terminal programs were actively storing all of data they read out of pipes into memory before displaying it, rather than a read-some/print-some informally buffered approach. Similarly, I don't think holding the data in the "displayed output" state is going to OOM your terminal out of the box: I get the impression that most terminal programs have a fairly conservative history-line-buffer size in order to avoid this family of problem.
This isn't the same as crashing/hanging your terminal's command-output parser (depressingly easy in Upterm) due to volume; when that happens, the process writing tons of data (cat my_huge_file.dat) will fill up its STDOUT pipe and usually block until the situation is resolved. I think that stability-in-the-face-of-large-output behavior is what you're referring to, rather than OOM killing, in which case I agree wholeheartedly that the behavior of terminal systems (and remote shell systems, etc.) is distressingly bad in the face of large-data influx situations.
Re: Upterm – A terminal emulator and interactive shell based on Electron
#107While I'm a sucker for beautiful terminal emulators, functionally, I can't use it yet. Vim with scrolling using the fn keys doesn't work, seems to get frozen. Tmux doesn't work on it either. In theory, I'd be a user in the future if I can customize it to my liking the way I can with iTerm2, but for now, I won't be adopting it. Starred the repo, so I'll be on the lookout for future updates :)
Re: Upterm – A terminal emulator and interactive shell based on Electron
#108Earlier quoted context omitted.
Maybe you could support a user-defined auto-completion config like Bash et al do for theirs and IDEs would for custom languages too. With regards to the shell input: I don't know how you are currently detecting the $SHELL prompt (and thus when you can do your auto-completion) but maybe you could allow users to specify hooks for what to watch for to determine the different between the $SHELL and other tools, based on…
It works differently: we just create a new shell session for each command. We create a non-interactive session without reading config files to make it fast and pass it appropriate ENV, which we maintain.
Ahh so the prompt isn't bash then? That explains some of the bugs I got.
I'm not going to criticize your approach as it totally makes sense in terms of building a minimum viable product but I do think you're going to run into a lot of problems with that approach as your project gains traction as it's very different to how a terminal emulators traditionally work. Plus you'll potentially spend a lot of time reimplementing Bash features like it's builtins, scripting features and the multitude of parsers it runs (depending on if you're interested in having a REPL environment like you would normally would with $TERM + $SHELL).
That all said, it looks like you're handling pseudo TTYs decently, which is an easy thing to get wrong (I say that from experience as I've screwed up PTYs in the past!) but also probably the most important part to get right, in my opinion.
Re: Upterm – A terminal emulator and interactive shell based on Electron
#109Hacker News macro: Author: I wrote something for people who care more about features than performance. People who care more about performance than features: I am personally offended that you created this.
typing latency (evident in all electron programs) is a deal breaker tbh - this becomes especially true for something like a term emulator
I don't notice any typing latency on Slack and I'm usually pretty sensitive to it. That said, Atom with a bunch of plugins can chug a little.
Re: Upterm – A terminal emulator and interactive shell based on Electron
#110While I'm a sucker for beautiful terminal emulators, functionally, I can't use it yet. Vim with scrolling using the fn keys doesn't work, seems to get frozen. Tmux doesn't work on it either. In theory, I'd be a user in the future if I can customize it to my liking the way I can with iTerm2, but for now, I won't be adopting it. Starred the repo, so I'll be on the lookout for future updates :)
That's strange. Vim and tmux work fine for me on MacOS.