
Black Screen: A modern terminal emulator based on Electron - SalGnt
https://github.com/shockone/black-screen
======
shockone
Hello. I'm the author of Black Screen, and I'm upset this post has appeared on
Hacker News. The terminal is at a very early stage; I don't even use it by
myself. Although, it's nice to see that people show some interest.

~~~
fibo
Can you use another npm namespace?

. 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.

~~~
shockone
I'm afraid you misunderstood the command. The package is named correctly -
black-screen. Install-all is a local npm script, that's why you run it with
`npm run`.

------
JulianWasTaken
One of these seems to pop up every few months, which is great, terminals are
old crusty awful things, but it seems like they always die out in development
before they can run existing things like Vim which makes them fun POC's and
not much else :/

~~~
ibrahima
I would really love it if one of these web-based terminals managed to stick
around. Just being able to view images in a terminal would be amazing. The
trouble with building on web technologies seems to be that the overhead is
just too high (eg. Atom) considering how many terminals the average developer
has open at a time.

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!

~~~
userbinator
_Just being able to view images in a terminal would be amazing_

What are the advantages of that over using a dedicated image viewer program?

~~~
techdragon
cat tmp.png

"Yep that looks like it's right"

git add tmp.png

~~~
Jach
Whoopee, you saved one keystroke (`eom tmp.png` "Yep, looks good. _Presses
Escape_ ") and if you become interested in any data from previous commands'
output you'll have to scroll up more / live with a larger window than
otherwise because now you've got an image sucking up n rows in your terminal.

~~~
klibertp
Look at IPython and DrRacket to see why inline images can be useful in REPLs.
With DrRacket you can not only view, but also create and combine images one
step at the time, always seeing the latest form of it. And then you naturally
end up with a script for doing the transformations needed to get your desired
result.

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).

~~~
Jach
Oh, I'm all for interactive development, one of the reasons I prefer dynamic
languages is precisely that, I just don't think the utility of having a static
(or animated, or auto-reloading ((!) changing output in a non-ncurses shell?!)
image in the shell is that useful compared to the engineering effort and what
feels to me the loss of the shell's essential character. ncurses is about the
limit of having enough control to make a game vs. having something that isn't
a shell interface anymore. The shell isn't a monolithic IDE which you only run
one instance of, the closest analogy I use is "vim+Linux are my IDE" and
terminal windows are just windows to interface with my "IDE" that I can run
any time. eom theoretically supports auto image reloading, though other
viewers definitely do. When I edit LaTeX files, I do so in vim, and have the
PDF open in evince/atril to the side which auto-refreshes when I save the file
(if I set up vim to run latexmk on save, otherwise it's just an extra command
I do). This is just the same when doing ClojureScript development -- your IDE
doesn't necessarily reload and try to support all the features of a browser,
the programmer just uses an actual browser to the side and you use whatever
IDE or text editor you like and a file monitor manages the auto-reloading
stuff.

------
mycelium
Screenshot looks awesome!

I get this error on mac os Yosemite, I made a github issue here:
[https://github.com/shockone/black-
screen/issues/21](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
            ...

~~~
tundrax
Appears to be gulp-typescript problem. Upgrading gulp-typescript to "^2.8.1"
solves.

------
blt
Bringing up a whole web browser engine for the terminal is a deal breaker for
me. I want it to start instantly. 1 second is too long.

~~~
shockone
That's understandable. It's like with editors. There is vim and there is
Intellij IDEA (sorry, JetBrains, for calling your child an editor). I want it
to be smart.

------
lazybum
I see it is buzzword-compliant, but what is it good for?

~~~
shockone
Ha-ha, I get that a lot after telling about React and Electron. Initially I
was thinking about Swift + Cocoa, but I figured CSS would give me more
flexibility in designing the UI, and it would allow more people to write
plugins. Everybody knows JavaScript, right?

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.

------
revelation
I kind of don't want to have my terminal emulator run a complete webbrowser
because that's how all the cool kids now pull off the Delphi window skinning
look of 2000.

~~~
landr0id
I think that what these JS-based UI toolkits are doing is really great, but I
really dislike the idea of bundling basically a browser with the application.

~~~
shockone
There is a positive side: a built-in HTML and CSS engine allows to write very
customizable interfaces.

------
arcameron
reminds me a lot of TermKit

[http://acko.net/blog/on-termkit/](http://acko.net/blog/on-termkit/)

looking cool!

------
eggsome
When I saw this post I thought it was going to be an xterm with an oldschool
CRT look. I got someone to build me one of those for playing rougelikes a few
years ago - see here if anyone is interested:
[http://ubuntuforums.org/showthread.php?t=1884955](http://ubuntuforums.org/showthread.php?t=1884955)

------
mamcx
Something like this, but with performant native controls?

I will love to build a interactive REPL "terminal" for some data tool I'm
building, but with a modern native GUI.

------
eeZi
iPython Notebook makes for a nice terminal emulator:
[http://jeroenjanssens.com/2015/02/19/ibash-
notebook.html](http://jeroenjanssens.com/2015/02/19/ibash-notebook.html)
(inline images!).

It lacks readline support, though, and does not implement all VT100 control
characters.

------
rtz12
Nice, another application that eats away tons of RAM because it comes with
it's own WebKit engine.

~~~
mycelium
I don't disagree, but as someone who has written a bunch of personal tools
(including a Tinder assistant lol) with electron and nwjs, think about why
people are using these runtimes before you rip on it. Since so many people are
doing it, there must be some good reasons.

~~~
rtz12
Yes, they are using it because they are familiar with the web platform and
want to go a step further. But that doesn't mean that all other ways to build
programs for desktop use suck and we can only use a webkit engine. With stuff
like electron, the result is bloated as hell and looks totally foreign.

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?

------
jestinjoy1
Related: [http://xiki.org/](http://xiki.org/)

------
epmatsw
Bummer. Doesn't compile with iojs.

~~~
chjj
It looks like it uses "child_pty" to spawn pty's. child_pty hasn't been
updated to support the latest nan/v8 api (in fact, it looks like it's been
unmaintained since March). It also improperly uses fs streams to read and
write to the pty fd which will exhaust the thread pool very quickly. So, even
if you can compile it, it will still break.

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.

[1] [https://github.com/chjj/pty.js](https://github.com/chjj/pty.js)

~~~
shockone
Thank you for the advice. Pty.js was my initial choice, but it didn't support
return codes at the moment. I'll take a look at it again.

------
supster
This looks really awesome - can't wait to try it out!

