I'm afraid it's not going to happen any time soon, if at all. But even if it does happen, it won't be cmd.exe or PowerShell support, but rather some kind of POSIX shell for Windows.
Almost all my terminals are ssh'd into some remote machine. Do you still get the features like enhanced command line completion in this scenario? What about integrated screen/some other kind of reconnection?
It's theoretically possible to have all the Upterm niceties over SSH, but not possible at the moment. As of screen and tmux, we have no plans to integrate with them.
I made a superficially similar thing but I've never released it.
My differences:
(1) The shell is in pure js. It's a thin wrapper around shelljs but I had plans to move to a builder type syntax, eg. fs.cp().f("/tmp/foo").t("/tmp/bar").x();
(2) I made an api so people could quickly code up graphical output for commands.
Just wondering if you'd be interested in integrating a feature like this. Do you have a chat channel?
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 expected bugs with any new terminal emulator. For example it took me 5 minutes to just cd into a directory because env vars weren't being recalled, the ~ variable wasn't being recalled, and auto-complete wasn't keyboard optimised (I'd arrow down and hit enter but it would crop the line rather than select the auto-complete entry).
So the next thing I did was to start my preferred shell and I then ran into a whole other series of bugs due to the terminal emulator being tailored for it's own specific shell. In fact the bugs there were so severe that it renders the term virtually unusable on any of the standard shells nor the more esoteric ones I contribute to.
One thing I was pleasantly surprised about though was how well it supported ANSI escape sequences - even ones that aren't part of the formal standard (such as the iTerms true colour sequences). But the bugs surrounding the terms handling of readline (and similiar) really feels like many of the basics are missing despite having some cool advanced features already.
Overall, as much as I'm ideologically against Electron, I can see the advantages of using it in this domain because it allows the ability to include rich content in the command line. It might be nice to get to the point where the command line can offer as much rich content as a web page (something I'm working towards with my own project in fact) - in which case Electron (or similar tech) seems the obvious choice for building a terminal emulator. However upterm's dependance on using your own implementation of Bash (I think it's a bit disingenuous calling your shell "Bash" but that's your prerogative) makes this highly frustrating compared to other rich terminal emulators already out there. And the inability to run your own shell within upterm makes this inflexible for anyone wanting to do something a little more indepth than just cat'ing a JSON file (even running a DB command line tool like mysql or redis-cli would be impractical in upterm in it's current state. And while I didn't try SSHing into remote boxes I can see the same issues happening there too).
I don't know the age of this project but I think it does have real potential. However if I was to ask for anything - and I appreciate this is your baby so I have no entitlement what-so-ever - it would be if you could offer a $SHELL'less version for power users.
edit: Also, I've noticed commands that fail don't appear in the upterm's history. Was this an intentional decision? I appreciate there are arguments for and against only including successful commands but sometimes you'd typo something and the inability to up-array and edit my failed commend added to my frustration. If this was an intentional design decision then is it worth including the last command regardless of success and then excluding it from all subsequent placements in the history?
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 or readline replacement). The core issue is that shells' interface is too primitive: it only consists of three streams with no per-job separation or anything; I wish Bash had a programmatic or REST-like interface.
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
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).
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.
We really need a modern take on terminals, so keep up the good work.
I know there is a lot of clash around electron apps these days, and I'm the first one to dislike the waste of resources. But maybe in 5 years electron and hardware will improve so much it won't matter anymore. So if it allows you to experiment with new stuff, keep going.
There's like 1,000 programming languages and we don't need most of them. If a new language is truly amazing, by all means use it, but if it's hated by everyone I don't know why you'd choose it over something like C or Python or Perl which most developers seem to agree are the "good" languages.
I don't know any of the above mentioned languages myself, so beyond that outsider perspective I can't form an opinion on it, I am just curious why this choice was made.
Surprisingly it has pretty moderate resource usage. I have both iTerm and Upterm running on my laptop, here are the stats. Of course, your mileage may vary.
Hyper is a pure terminal emulator; it only displays what your shell tells it to display. We aim to deeply integrate with a shell or even replace it for better experience. One of the most notable benefits is as-you-type intellisense completion with fuzzy search and stuff. There are some animations on the releases page: https://github.com/railsware/upterm/releases
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?
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.
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 per second. Upterm is good at both.
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/
Usually performance in GNU yes is a canary for other bad performance. Its more like saying "if you can handle yes, you can handle anything." I've legitimately crashed hyper term (another electron-base term) when dumping other large amounts of data, like in large log files.
> 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.
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.
It's just the matter of personal preference I guess... I have good enough completion for terminal with my current ZSH configuration. (I am not fan of auto completion even in IDEs and editors) One thing I need from few tools that I use everyday (terminal and text editor) is as low latency as possible, I get really irritated by all those few ms of lag that are visible after keypress, I don't know why. So any Electron app is no go for me from the start, so I decided to stick with Vim and Emacs. Only GUI editor that blew me away by it's performance is Sublime.
A bit off-topic but I wonder if it is possible that Electron team distribute something like the VS C++ Runtimes on Windows? And release patches for different versions/updates?
Haven't used a Windows machine for a while but I remember there were bunches of different VS Runtime version installed on my PC before. Some app installers came with a runtime installer, but if the required runtime version was installed it would just use that one. I think this might somewhat reduce the installed app size for Electron apps as at least some stuff got reused.
You can approximate this somewhat today by distributing only an .asar or .zip archive of an application package and encouraging:
npm install -g electron
electron ./myapp
Or as npx gets more widely deployed:
npx electron ./myapp
That's not a particularly "robust" way to install applications and you can't use native libraries outside of the base Electron distribution, and you'd mostly only be useful to devs with NodeJS already installed, but it's an option of a sort.
(It still won't share as much runtime memory as you might want, but it would reduce install footprints at least.)
There's also experiments like electrino [1] to force more use of platform webviews since all of our platforms have a webview built in anyway, trading some additional testing for bundling Chromium everywhere.
I'm surprised that I haven't yet seen a fork of electron-windows-store [2] that makes use of the UWP webview, as that seems an obvious enhancement to me. The Electron remoting between webviews and Electron code is already setup well enough you should be able to run the Node app as a UWP background app and use UWP remoting.
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 an awful lot of work.
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.
We kind of experimented with parsing man files, but it'll never be as good as manually crafted suggestions: you can do stuff like suggest changed files for "git add", tokens from diff for "git commit" message, show process names for "kill", and much more. The vision is to have manual suggestions for at least the most popular tools.
I do man parsing for one of my projects and it is as painful as HTML parsing. OK the syntax is less complex but you still end up with the problem that the body of text is designed for human consumption so the formatting doesn't always follow the same rules from one man page to the next (tokens aside).
This means that while it is easy enough to pull flags from the man pages, offering usage suggestions is something too tricky to handle in an automated on-demand fashion.
I did toy with the idea of starting a new project porting man pages to a new document format designed specifically for utilities parsing (eg a JSON format with standardised fields). However even that would be a massive job to maintain without the support from other developers upstream.
But I'm open to other suggestions if anyone has any?
I'm not going to spend hundreds of megabytes to display text on the screen. Not to mention the input latency this will have between keystrokes. The style of autocompletion shown can already be achieved with zsh - autocompletion should not be a function of your terminal emulator, but rather your shell.
However, this is all just my opinion and maybe there will be a load of users, me and people who share my opinions will slowly descend into obsolescence.
It's your choice, of course, but in my opinion Electron is the only decent cross-platform UI framework. Without Electron there would be no Linux version.
Any Qt app can be themed with CSS (Qt calls it QSS) as if it was an HTML page, just like Electron apps can be. You can completely change the design, if you wish to.
So, in terms of design, there’s basically no major difference there.
Really? I joined a few groups but couldn't figure out how to post, and there was an emoji drawer eating up 1/3 of the screen, and was unable to be hidden. I consider myself a smart enough person to write an app that performs the role of Telegram, I shouldn't have trouble learning to use it.
Of course it depends on where your interests lie but here's some examples: VLC, Spotify (Linux), old Opera, Krita, Google Earth, Tesla Model S in-car UI, webOS, SailfishOS, AMD's Radeon Software Crimson driver tool, and many others including what's already mentioned, Battle.net.
it's not like there are hundreds of cross-platform win/mac/linux software that have no problem being written in other frameworks than electron. See all the KDE apps, Krita, Inkscape, GIMP, Wireshark, Audacity, Unity3d, Maya, Houdini, Blender, LibreOffice etc etc which are all hundreds of time more featureful that your average Electron app.
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 improvements to Conemu making it more intuitive and user friendly.
If you are looking for a terminal to use with cygwin then you should check out http://extraterm.org . It is in development but is stable enough for me to use full time on Linux and cygwin. Plus it has a bunch of other useful features.
Tried it several months and left unimpressed. While by what the product aspires to be, it could be the IDE for command line, it's far from that. The only difference is essentially autocomplete, which is not intelligent (and probably can't be, nothing along the lines of parsing --help or man pages) and felt clunky when trying to edit part of a command and then try to get another "suggestion".
With zsh's built-in Ctrl+R it's at least possible to reduce list of suggestion and then travel up the history in those suggestions. While the more powerful fzf will give you the list of commands you've run in a selectable dropdown.
Upterm I think could be eliminating entire classes of tools which sometimes are unnecesary complex. Server automation could be part of pre-saved playbooks which are saved to your terminal history and can be easily brought up and run according to rules. Curl arguments could be arranged in a way where they are actually managable. Parsing --help and man pages (which is possible, there is a workable implementation in fish AFAIK). Upterm is in position to take on that functionality, but right now it's not much more than already mentioned hyper, but with custom handled prompt line.
Gosh, please stop making these. I'm not even going to pretend to have anything but disdain for this project. There's a serious lack of engineering accumen among the users of Electron.
If Atom is any benchmark, plugins will be created, abandoned, forked, abandoned and then the API will churn breaking everything every so often because "change is cool." It's the same segment of programmers with 0-6 months of experience whom can't be bothered to delve deeper into computer science, professsional software engineering or static compilation. Instead, just waste everyone's RAM and processor cycles with inefficient interpreted scripts and also bounce from shiny tech to new shiny tech.
I don't know how you could expect the project's developer(s) to read your comment and gain anything positive from it. It's a thinly veiled rant / grab at votes. There are a lot of ways you could be more constructive, and you decided to not go with any of them. :)
I don't. They're 2000+ commits deep into this mess, it's not like they're going to change course now. I'm hoping to discourage everyone else from building similar projects.
Easy there, this is someone's personal project- you aren't being forced to use, evaluate, contribute to, or provide a review. You should focus on your own goals and excuse yourself from topics of discussion you don't care for. Someone on the project is likely reading this and -not- feeling good about your needlessly hateful comments. Next time just keep it to yourself and move on.
No, if I don't speak up, these bad engineering practices proliferate and the ecosystem gets worse. Sorry, but people are going to be called out on their mistakes and that's fine.
Like 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.
Taliing about integration, I like terminals with good mouse support, where one can plumb the selected text with a click.
For some reason, there aren't so many, except
- 9term from plan9,
- tilix or tylix, which has customisable actions for regex patterns
- URL, mostly http, in vte based terminal
I wrote a simple patch for st that process some escape sequence from the shell to have the terminal aware of its shell current working dir (ocs7).
Using this simple hack, one can just cd & ls & select "foo.pdf" & right click to have it handled by one ´s plumber (open, xdg-open, plumb ...) or even right click "path/to/file:line:column" from a log to the editor.
This feature is so simple, so addictive in plan9/acme, that I don't really get why it isn't offered by most terminals.
I don't notice any notable latency in discord, vscode, etc
But I do notice latency in hyper.js, and it just makes it feel very "dull", and that's what I think a lot of people know of electron terminals
plus the competition from native apps is a bit absurd in terms of performance, with most of the serious ones either rendering asap or on the next frame (when vsync'd)
and why would your experience of one terminal app based on Electron apply to all other terminal apps based on Electron? You even say that you don't notice latency in VSCode. A text editor and a terminal have similar problems to solve.
I would of tested this one, but no windows build, and I'm not using a linux install atm
editors don't roundtrip to a separate application through multiple buffers (bash, zsh, fish, or whatever) to decide if they need to show a color or letter or nothing
Fish seems to work wonders for me. I've been using it for more than a year and it works well. I welcome new developments for sure.
Autocomplete that was a little bit laggy on zsh simple works super fast on fish. Other features are also very nice. I think people who might be interested in this, might find fish interesting.
While 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 :)
I don’t get the hate for things built on electron. The technology is awesome.
Have some patience. It will eventually improve to the point where it is very low overhead and provides much richer experiences than we have in the terminal today.
Nobody is forcing you to use it today. Just be supportive because we want it’s future.
> Have some patience. It will eventually improve to the point where it is very low overhead and provides much richer experiences than we have in the terminal today.
This is a very optimistic of framework/technology performance.
> Nobody is forcing you to use it today. Just be supportive because we want it’s future.
Using web stack for desktop application wasn't a technological choice. It's a much more a reflection of the inability of our industry to cohesively innovate
126 comments
[ 0.15 ms ] story [ 163 ms ] threadi.e.
`cd $THAT_ENV_DIRECTORY`
however I always get
`The directory "$THAT_ENV_DIRECTORY" doesn't exist. `
although clearly it does as it is autocompletion suggested
My differences: (1) The shell is in pure js. It's a thin wrapper around shelljs but I had plans to move to a builder type syntax, eg. fs.cp().f("/tmp/foo").t("/tmp/bar").x();
(2) I made an api so people could quickly code up graphical output for commands.
Just wondering if you'd be interested in integrating a feature like this. Do you have a chat channel?
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 expected bugs with any new terminal emulator. For example it took me 5 minutes to just cd into a directory because env vars weren't being recalled, the ~ variable wasn't being recalled, and auto-complete wasn't keyboard optimised (I'd arrow down and hit enter but it would crop the line rather than select the auto-complete entry).
So the next thing I did was to start my preferred shell and I then ran into a whole other series of bugs due to the terminal emulator being tailored for it's own specific shell. In fact the bugs there were so severe that it renders the term virtually unusable on any of the standard shells nor the more esoteric ones I contribute to.
One thing I was pleasantly surprised about though was how well it supported ANSI escape sequences - even ones that aren't part of the formal standard (such as the iTerms true colour sequences). But the bugs surrounding the terms handling of readline (and similiar) really feels like many of the basics are missing despite having some cool advanced features already.
Overall, as much as I'm ideologically against Electron, I can see the advantages of using it in this domain because it allows the ability to include rich content in the command line. It might be nice to get to the point where the command line can offer as much rich content as a web page (something I'm working towards with my own project in fact) - in which case Electron (or similar tech) seems the obvious choice for building a terminal emulator. However upterm's dependance on using your own implementation of Bash (I think it's a bit disingenuous calling your shell "Bash" but that's your prerogative) makes this highly frustrating compared to other rich terminal emulators already out there. And the inability to run your own shell within upterm makes this inflexible for anyone wanting to do something a little more indepth than just cat'ing a JSON file (even running a DB command line tool like mysql or redis-cli would be impractical in upterm in it's current state. And while I didn't try SSHing into remote boxes I can see the same issues happening there too).
I don't know the age of this project but I think it does have real potential. However if I was to ask for anything - and I appreciate this is your baby so I have no entitlement what-so-ever - it would be if you could offer a $SHELL'less version for power users.
edit: Also, I've noticed commands that fail don't appear in the upterm's history. Was this an intentional decision? I appreciate there are arguments for and against only including successful commands but sometimes you'd typo something and the inability to up-array and edit my failed commend added to my frustration. If this was an intentional design decision then is it worth including the last command regardless of success and then excluding it from all subsequent placements in the history?
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 or readline replacement). The core issue is that shells' interface is too primitive: it only consists of three streams with no per-job separation or anything; I wish Bash had a programmatic or REST-like interface.
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:
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).
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.
I know there is a lot of clash around electron apps these days, and I'm the first one to dislike the waste of resources. But maybe in 5 years electron and hardware will improve so much it won't matter anymore. So if it allows you to experiment with new stuff, keep going.
And good luck.
I don't know any of the above mentioned languages myself, so beyond that outsider perspective I can't form an opinion on it, I am just curious why this choice was made.
The only caveat is that I'm not sure I want to have another electron app chewing through 15% of my CPU...
https://imgur.com/a/bwD06
Hyper + zsh can.
https://danluu.com/term-latency/ (Previous discussion: https://news.ycombinator.com/item?id=14798211)
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 per second. Upterm is good at both.
I dropped those because they're magnitudes slower than urxvt. You managed to make a terminal emulator that's even worse?
Not every tool fits everyone’s needs. Some tools might only be useful to a few people.
No need to be rude about it.
Considering I dropped those because I consider them slow and bloated, good luck with this Electron monstrosity.
You can have my RXVT when you pry it from my cold, dead hands.
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/
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.
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.
Haven't used a Windows machine for a while but I remember there were bunches of different VS Runtime version installed on my PC before. Some app installers came with a runtime installer, but if the required runtime version was installed it would just use that one. I think this might somewhat reduce the installed app size for Electron apps as at least some stuff got reused.
(It still won't share as much runtime memory as you might want, but it would reduce install footprints at least.)
I'm surprised that I haven't yet seen a fork of electron-windows-store [2] that makes use of the UWP webview, as that seems an obvious enhancement to me. The Electron remoting between webviews and Electron code is already setup well enough you should be able to run the Node app as a UWP background app and use UWP remoting.
[1] https://github.com/pojala/electrino [2] https://www.npmjs.com/package/electron-windows-store
it would be awesome if you had some way to support more commands - especially if done in a more automatized way.. parsing the manuals (?)
This means that while it is easy enough to pull flags from the man pages, offering usage suggestions is something too tricky to handle in an automated on-demand fashion.
I did toy with the idea of starting a new project porting man pages to a new document format designed specifically for utilities parsing (eg a JSON format with standardised fields). However even that would be a massive job to maintain without the support from other developers upstream.
But I'm open to other suggestions if anyone has any?
However, this is all just my opinion and maybe there will be a load of users, me and people who share my opinions will slowly descend into obsolescence.
* Make a decision you want completion.
* Press tab for it to appear.
* Guess when your token is precise enough to be unambiguous or else cycle through results.
Not to mention fuzzy search.
It may sound as not that much of an overhead, but it's so much slower than what I have in, say, Intellij IDEA.
Shouldn't be too hard to modify it to display completion data instead of entries from your history.
I prefer the other plugin though because it's less obtrusive.
No thanks
I'm not against electron app, in fact I think it's a really good idea. But saying it's the only good ui framework is disingenuous.
What about Qt, wxWidgets, Tcl/Tk, or even Kivy?
So, in terms of design, there’s basically no major difference there.
Battle.Net ? https://i.imgur.com/VCNEhgm.jpg
both are made with Qt
Of course it depends on where your interests lie but here's some examples: VLC, Spotify (Linux), old Opera, Krita, Google Earth, Tesla Model S in-car UI, webOS, SailfishOS, AMD's Radeon Software Crimson driver tool, and many others including what's already mentioned, Battle.net.
JavaFX? Also a nice cross-platform UI framework, supports JavaScript, and is also better performant than Electron.
Also, both support HiDPI by default, and can be themed with CSS however you want them (in the exact same way that you could theme Electron apps)
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 improvements to Conemu making it more intuitive and user friendly.
as said terminal emulator should do one thing lightly. Tough the nice interface still made me download it.
Try building the same stuff with smtg else than electron ?
With zsh's built-in Ctrl+R it's at least possible to reduce list of suggestion and then travel up the history in those suggestions. While the more powerful fzf will give you the list of commands you've run in a selectable dropdown.
Upterm I think could be eliminating entire classes of tools which sometimes are unnecesary complex. Server automation could be part of pre-saved playbooks which are saved to your terminal history and can be easily brought up and run according to rules. Curl arguments could be arranged in a way where they are actually managable. Parsing --help and man pages (which is possible, there is a workable implementation in fish AFAIK). Upterm is in position to take on that functionality, but right now it's not much more than already mentioned hyper, but with custom handled prompt line.
Also, we recently integrated monaco-editor by Microsoft, so editing is much less clunky than it was before.
I'm not a fan of Electron, but I don't see this correlation at all.
For some reason, there aren't so many, except - 9term from plan9, - tilix or tylix, which has customisable actions for regex patterns - URL, mostly http, in vte based terminal
I wrote a simple patch for st that process some escape sequence from the shell to have the terminal aware of its shell current working dir (ocs7). Using this simple hack, one can just cd & ls & select "foo.pdf" & right click to have it handled by one ´s plumber (open, xdg-open, plumb ...) or even right click "path/to/file:line:column" from a log to the editor.
This feature is so simple, so addictive in plan9/acme, that I don't really get why it isn't offered by most terminals.
It sure results in exciting and interesting bugs, if you look at upterm's issue tracker.
Except, you know, all of the folks that say that they like Atom or Visual Studio Code: https://insights.stackoverflow.com/survey/2017#technology-mo...
(Atom and VS Code were specified by 20% of voters in each category).
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.
But I do notice latency in hyper.js, and it just makes it feel very "dull", and that's what I think a lot of people know of electron terminals
plus the competition from native apps is a bit absurd in terms of performance, with most of the serious ones either rendering asap or on the next frame (when vsync'd)
I would of tested this one, but no windows build, and I'm not using a linux install atm
editors don't roundtrip to a separate application through multiple buffers (bash, zsh, fish, or whatever) to decide if they need to show a color or letter or nothing
Autocomplete that was a little bit laggy on zsh simple works super fast on fish. Other features are also very nice. I think people who might be interested in this, might find fish interesting.
Have some patience. It will eventually improve to the point where it is very low overhead and provides much richer experiences than we have in the terminal today.
Nobody is forcing you to use it today. Just be supportive because we want it’s future.
This is a very optimistic of framework/technology performance.
> Nobody is forcing you to use it today. Just be supportive because we want it’s future.
Using web stack for desktop application wasn't a technological choice. It's a much more a reflection of the inability of our industry to cohesively innovate