Live data from Hacker News

Upterm – A terminal emulator and interactive shell based on Electron

github.com

61–70 of 127 posts

Re: Upterm – A terminal emulator and interactive shell based on Electron

#61
post #60

Earlier quoted context omitted.

Performance is definitely worse than in iTerm or gnome-terminal, but it's improved a lot in recent Upterm versions, and we plan to improve it further. I'd say it's good enough, but you can try yourself. Recently there was this terminal performance test https://danluu.com/term-latency/ The author says that the most important things are typing delay and how quickly you can Ctrl+C a command, not how much text it prints…

> Performance is definitely worse than in iTerm or gnome-terminal I dropped those because they're magnitudes slower than urxvt. You managed to make a terminal emulator that's even worse ?

Hey, I bet nobody will force you to use it or help develop it.

Not every tool fits everyone’s needs. Some tools might only be useful to a few people.

No need to be rude about it.

Re: Upterm – A terminal emulator and interactive shell based on Electron

#62
post #60

Earlier quoted context omitted.

Performance is definitely worse than in iTerm or gnome-terminal, but it's improved a lot in recent Upterm versions, and we plan to improve it further. I'd say it's good enough, but you can try yourself. Recently there was this terminal performance test https://danluu.com/term-latency/ The author says that the most important things are typing delay and how quickly you can Ctrl+C a command, not how much text it prints…

> Performance is definitely worse than in iTerm or gnome-terminal I dropped those because they're magnitudes slower than urxvt. You managed to make a terminal emulator that's even worse ?

I don’t mean to spark a controversy, but that’s what happens when you use Electron.

Re: Upterm – A terminal emulator and interactive shell based on Electron

#64
post #55

Earlier quoted context omitted.

I've given this a play and I hope you don't mind some constructive criticism I've experienced: First of, I really like the idea of this project despite normally being a vocal critic against Electron. However I think you bit off too much trying to write your own $SHELL as well as terminal emulator. The result is rather uncomfortable to use because there are shell bugs and incompatibilities compounding the usual expect…

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 the $SHELL prompt (possibly using $PS1 env var?)

For example you could define that $SHELL's prompt would be:

    SHELLPROMPT>
And when you read that from the $SHELL's STDOUT you know the shell is waiting for prompt. There is obviously the danger that your term would get confused if SHELLPROMPT> happens to appear in the STDOUT when not part of the prompt that it would confuse your term, so perhaps you might need to include an ANSI escape sequence in there as well. Or maybe even define your own custom ANSI escape sequence that $SHELL's need to include in their prompt? (I'm mostly just brainstorming at the moment so these ideas might be worse than your current implementation).

As a side note, the project I'm currently working on is a $SHELL that supports defining data types to STDOUT and STDERR. The issue I have is that those byte streams are typeless and scripts written in my $SHELL needs to work with existing POSIX utilities and potentially on other $SHELLs with untypes streams. Plus I wanted people to be able to type those streams from other languages as well if they wanted and for my $SHELL to understand that. The solution I've decided upon was for an ASNI escape sequence to surround a string with the typed information and for this to only be a included if an environmental variable was set to the name of my shell. This is how I'm working around limitations with POSIX compatibility while still offering a richer environment to develop in when my $SHELL is running (I hope that makes sense).

In fact it sounds like we are attempting to solve similar problems but from a different angle - with myself targeting the $SHELL while you are targeting terminal emulation (which it probably why I'm warming to your project).

Re: Upterm – A terminal emulator and interactive shell based on Electron

#65

Earlier 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…

As of history and failed commands, it should work as you describe, it must be a bug. https://imgur.com/a/BKz5O

If it is any help, the issue happened with Bash builtins like `cd` and `while`. So it's possibly related to the problems you mentioned in the other reply

Re: Upterm – A terminal emulator and interactive shell based on Electron

#67
post #6

How'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 that are very important, and you may have meant to point towards those, but as it is this comment just reads as bikeshedding. "Performance is (a|the most important) feature" refers to performance in areas that matter.

* And yes, I know that yes(1) can be used for performance/stress testing of systems by outputting endlessly. Doing that to a human-consumed TTY seems like an example of spacebar heating: https://xkcd.com/1172/

Re: Upterm – A terminal emulator and interactive shell based on Electron

#69

I've not been able to find an adequate terminal emulator for Windows. I found Conemu clunky (maybe I needed to spend more time configuring it, but out of the box it was fairly ugly, and borked out under some curses applications and when using tmux), PuTTY/KiTTY to be lacking some important features (like tabs) -- ditto cmd.exe. IMO there's a real gap in the Windows market, be that a new terminal emulator entirely, or…

I'm using http://cmder.net/

Re: Upterm – A terminal emulator and interactive shell based on Electron

#70

Earlier quoted context omitted.

In my opinion, Qt and wxWidgets apps look ugly. At least I never saw one that looks beautiful.

Telegram ? https://raw.githubusercontent.com/telegramdesktop/tdesktop/d... Battle.Net ? https://i.imgur.com/VCNEhgm.jpg both are made with Qt

I didn't know Telegram uses Qt. No desktop messaging client has better UI/X.
Post reply on HN