shockone
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.
Also, we recently integrated monaco-editor by Microsoft, so editing is much less clunky than it was before.
* 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.
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.
So, I use a terminal emulators pretty extensively, and I'm tired of their dumbness. Compare any operating system from 1980 and 2015 - there is a huge difference. The same with web-sites, text editors, and pretty much any other category of software. Except terminals. The biggest achievement they made is 256 colours support. Good job!
It doesn't take a genius to understand that the limitations are caused by the text user interface. Of course, text is a great and universal tool. It's easily parsable (or not so easily, but still parsable). It can be piped, after all.
But who said we can't take the good old text and present it beautifully? Imagine you fired an sql client, wrote a select statement and received an ASCII table as an output. Wouldn't it be useful if the terminal understood that it looks like a table and converted it into an HTML table, with sorting by any column, resizing, filtering, and everything else. The same with XML, JSON and every other format: why should I type `jq` after a command that outputs JSON? Is that so hard to just detect and parse it for me?
Output formatters was the idea that made me start the development. I also plan to let users write custom formatting plugins.
But even besides that point there is a lot of room for improvement in current terminal emulators. For example, I have a git branch displayed in RPROMPT of my ZSH. It works well, but if I checkout another branch from a different place, my shell will still show the old branch, which can have certain consequences, if you rely on it.
The current feature I work on is autocompletion. I plan to parse man files and provide only what can be displayed in that place. By the way, folks from the Fish team do the same.
Unfortunately, right now Black Screen can not be used as a replacement for your favourite terminal, it has a long path to the first release.
Perhaps unexpectedly, Black Screen is both a terminal emulator and a shell. I tried hard to avoid going with writing a shell, but the existing ones simply don't fit. It's even hard to know when a child execution has finished. And I want smart autocompletion, so I have to at least extend a shell.
Traditionally these two are separated, and it must be a good design, but my current goal is to prove the concept. Perhaps, later I'll extract the shell.
By biggest concern is how to cat a 50MB file. If you try it now, everything gets stuck.
The problem with terminfo is that not every tool relies on it. I've seen many examples (hello, exa), when the codes are hard-coded to operate with xterm-256. So, I decided to pretend to be an xterm.