Black Screen: A modern terminal emulator based on Electron
github.com
github.com
Pretty cool looking project though, I have been thinking about something like this for a while now. The two biggest problems seem to be performance(I spawn throwaway shells all the time, so my terminal emulator need to open pretty much instantly), and fully compatibility(I use vim in the terminal as my main editor).
I'll be watching to see how it turns out.
By biggest concern is how to cat a 50MB file. If you try it now, everything gets stuck.
A new terminal/shell is a very hard sell, as I know from my own experience. Six years ago I wrote my own terminal/shell combination ( http://wiki.tcl.tk/23446 ). It works well enough that I've been using it myself full-time at work ever since, but although a few other people have tried it, no-one else ever adopted it. My own attempt is implemented in Tcl/Tk, an older but much lighter-weight framework (it has no problem with cat-ing a 50MB file).
I combined the functions of shell and terminal because I found the shell/terminal split made some of the functionality I wanted difficult or impossible. One example is that I colour text written to stderr in red - standard shells mix stderr and stdout together before the terminal even sees them.
I decided early on that I would not support terminal escape sequences. I set the TERM environment variable to "dumb" which tells well-behaved programs not to use escape sequences. So you can't run vi/vim in one of my windows, but I always use gvim so I don't find this a problem.
Similarly after some experimentation I decided not to use ptys as they created as many problems as they solved. So programs which change behaviour based on whether they are connected to a terminal behave as if running from a script. Eg. running "man command" lists the whole man page rather than trying to page it - but this is what I want since one can page up/down in the shell anyway.
However it seems that people who use a terminal get very attached to its idiosyncracies and will reject anything even slightly different. Since it's very difficult to make any real improvements without introducing incompatibilies, attempts at improving the terminal/shell user experience rarely catch on. In contrast, a few other tools I have implemented using the same technology have been adopted by a worthwhile user community at work. I think the difference is that they are used for more specialised tasks and don't require the user to change their everyday workflow.
Anyway, good luck with your endeavour!
. npm install black-screen
is far better t'han "install-all" for many reasons: better npm search, no namespace pollution, more semantic than such a generic name.
Please consider to change it.
Just like the web itself, any new teminal client needs to be backwards compatible with the capabilities of prior terminal clients, because programs that run in the terminal expect it. And if your terminal can't run the programs everyone runs in their terminals, no one will adopt your terminal. But many of these projects seem to have no intention of maintaining that backward compatibility. Some, like TermKit, fully conflate the terminal and the shell and even many UNIX utilities.
You can't hope to supplant ANSI compatible terminals when you let them have the enormous advantage of running all the software anyone wants to run in a terminal that already exists. It would be like saying you have a new, better web browser that can't open any existing web pages.
No idea if this particular project has learned from past examples and is backwards compatible or not. (EDIT: It doesn't have a terminfo page, so probably not.)
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.
The problem I see is that you seem to have the terminal doing things like fuzzy matching input against PATH executables. But that's the shell's domain. The terminal should just expose commands for adding text items to a drop down under the cursor, and the shell should send the matches to the terminal. And capabilities like this should be clearly defined in a terminfo page (which you should definitely have, even if for non-custom capabilities it uses the same definitions as xterm), so that well-written apps can send this information if and only if those capabilities are defined.
Of course this is a huge challenge, because if you do it this way your terminal doesn't do anything new until someone writes a program to run in it using its extended capabilities. So this creates a chicken and egg problem. But you can't come up with nearly as many interesting things for your terminal to do with cursor dropdowns as everyone in the world can if you're just exposing that in the same way the character grid is exposed.
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.
As they say above, this thing would halt when you cat a 50MB file.
It takes someone who's familiar with terminals, and can use a language fit for the task (and without too many depenedencies -- so if you built it in Haskell and I need the Platform and half of Cabal to build it, it will never fly -- and it being in Haskell it will not attrack many UNIX hands, who are the people familiar with Terminals most).
So something like C, C++, Rust or Go.
`cat 50mbfile` will not halt a web based terminal if you don't keep it all in the scrollback buffer.
I guess at least since it's based on Electron, it might have more longevity than something built from a cobbled together base. Here's hoping!
Several hundred MB RAM usage for a single Terminal window are just not acceptable.
Somehow many devs today write their software under the assumption that a user with 2GB RAM or 4GB RAM will at all times only run one single piece of software.
Like I know ranger has an option for it, but iirc there's also a way to just run a command ala `cat`ing a text file. If you'd like, I can look into it more if you can't already find out how to do it by searching.
Also, people are mentioning feh, I'd like to plug in sxiv (not my program though).
However, I'm sad to say that when I tried this again rn, it didn't work anymore. (I know for a fact it used to work great because I used to use it.)
The funny thing is, ranger's image preview still works for me (same terminal and everything), so I guess one could start going through the ranger source code to see how they wrap w3mimagedisplay if they really wanted to.
I don't really have the motivation for that though because, although I'm a heavy terminal user (and it would be nice), recently switching to emacs means a lot of my file management can be done with dired (an emacs package). And dired can do image previews quite nicely already [3] (I'm assuming provided you're using GUI emacs^). ^^
^Emacs can fire up terminals inside it anyway, so using GUI emacs is not a problem for me, even though I'm heavily terminal orientated.
^^Although I think I prefer sxiv's thumbnail mode for browsing directories full of images (as opposed to a few here and there).
[1]: http://blog.z3bra.org/2014/01/images-in-terminal.html
And yes, iTerm2 also displays animated gifs.
What are the advantages of that over using a dedicated image viewer program?
Even giving the ability to set a specific pixel to a specific rgb value would get far. Yes, some programs would get it wrong or would be annoying to use. But think what it would enable. Even at 3 fps, you could still show the user a performance graph of your program, or a flame chart. In the terminal. No extra windows required, no fiddling with GUI frameworks, just "set some pixels to some values."
In the short term, being able to set text to a specific foreground and background rgb would be nice. I'm talking 24-bit color. It turns out that this is not possible across all Unix variants: OS X default Terminal doesn't support 24-bit color for text. And there's no reason why it should be like that. The standards are in place, and they are a straightfoward extension to exiting behavior. The toolmakers just haven't enabled the other makers to use it. Of course, it's because it makes no sense for Apple to waste engineering cycles on that. But that doesn't change that it would be true that if they gave us better tools, we would do more.
The issue is that it has to be a minimum spec that's supported by all platforms. (All Unix platforms would be fine.) Simply writing a program that supports a nonstandard way of setting pixels to values wouldn't cut it. At least at first. That's probably how it has to start, though, in order for others to follow.
Combine it with dwm :)
"Yep that looks like it's right"
git add tmp.png
In short: the time savings introduced by shortening the feedback loop tend to add up. There is a reason why Web developers now use auto-reloading solutions, despite the fact that it saves "just one keystroke" (F5 in this case).
http://superuser.com/questions/246825/open-file-from-the-com...
(I suppose a similar thing could be done on *nix with a suitably modified execlp()/execvp().)
On Linux you should be able to wire up binfmt_misc, the plugin system for execve, to xdg-open.
Then you could just call that external difftool when comparing images:
git difftool --tool img-diff
Do you --or anyone reading this-- have a list of these? I would love to check them all out actually (not that I don't get your point).
Not really, they're just poorly documented. They're based on ad-hoc standards that are scattered across many outdated documents.
It'd be nice if somebody could actually pull all that together and publish one comprehensible document that is readable and up-to-date.
I get this error on mac os Yosemite, I made a github issue here: https://github.com/shockone/black-screen/issues/21
black-screen$ gulp
[17:35:09] Using gulpfile ~/black-screen/gulpfile.js
[17:35:09] Starting 'default'...
[17:35:09] Starting 'watch'...
[17:35:09] Starting 'clean'...
[17:35:09] Finished 'default' after 359 ms
[17:35:09] Finished 'clean' after 58 ms
[17:35:09] Starting 'typescript'...
[17:35:09] Starting 'sass'...
[17:35:10] Starting 'react'...
[17:35:11] gulp-notify: [Black Screen Watcher] React has been compiled.
[17:35:11] Finished 'react' after 1.83 s
~/black-screen/node_modules/typescript/lib/typescript.js:35171
if (host.fileExists(fileName)) {
^
TypeError: undefined is not a function
...Overall, actually really like the interface and the potential behind it. Super laggy and could use some work.
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.
Thanks to people insisting for years that the TTY is just fine, we don't appear have any other options. Ideally, we'd have progress - but as it is, we have nothing, or a shit sandwich. Forgive me for not going for nothing.
And, who's "we" when you say "We're planning to get all the major toolkits migrated to DisplayWebKit"?
I'm not trying to be argumentative, I just don't get where you're coming from.
http://acko.net/blog/on-termkit/
looking cool!
I will love to build a interactive REPL "terminal" for some data tool I'm building, but with a modern native GUI.
It lacks readline support, though, and does not implement all VT100 control characters.
EDIT: Just think of the major performance problems these electron based editors had and still have. Our compurters have become faster, so we just write more bloated and slower software?
It also looks like it doesn't handle sigchld with a waitpid anywhere, so be prepared to have a zombie apocalypse on your machine.
I'd recommend the author switch to pty.js[1] which now compiles on io.js >=3.0.0 and reads pty fd's properly, but I'm biased.