
Black Screen – Both a terminal emulator and an interactive shell - yankcrime
https://github.com/vshatskyi/black-screen
======
akanet
I think there is a stunning amount of "resource cynicism" in this thread. Yes,
this application uses much more RAM and CPU than a "normal" terminal emulator.
The project author is clearly trying to explore other ways that terminal
interaction could work, and is using a well known framework to accelerate this
process. If you use this project, you're using it to experiment with a new way
of working with the terminal, not to get screaming fast GPU accelerated screen
rendering. Potentially discovering new, valuable ways of working with
computers is worth doing, and should be encouraged.

~~~
na85
You appear to be suggesting we forgive the project for its poor memory
footprint because Electron was used as a sort of rapid prototyping tool to get
v1.0 out the door.

I think you know just as well as everyone else that this project's use of
Electron is unlikely to be an interim measure. It will (probably) always be a
resource hog, just like Chrome will (probably) always be a resource hog.
That's a conscious choice that is here for the duration.

Using Electron may have accelerated the process but let's not pretend that the
author is going to rewrite it in something more performant once a little
traction is gained.

~~~
akanet
I'm not suggesting that at all. I'm saying this project would likely not exist
in any form without Electron. If the ideas expressed within are successful
enough, realistically speaking people would either:

    
    
      1. continue using it despite the footprint
      2. merge similar ideas into other emulators
      3. fork and rewrite in whatever the next paradigm for expressive UI apps is (with hopefully a smaller footprint)

~~~
markmark
So many people miss this. This project (and many others like it) wouldn't be
faster without Electron. They flat out wouldn't exist.

If people don't want to use Electron apps then don't, but don't fill every
single discussion of an Electron app with the same old whining.

------
helb
On HN 2 years ago:
[https://news.ycombinator.com/item?id=10176289](https://news.ycombinator.com/item?id=10176289)

Tried it again today, replacing urxvt+zsh for an hour or so. Most of these
problems are probably due to the fact they use a custom shell:

\- ctrl-r (history search) just reloads the electron window and clears
everything [0]

\- does not work with virtualenv (bin/activate just messes up the shell to the
point where even `ls` stops working – `Black Screen: command "ls" not found.`)
[1]

\- weird tab completion

\- none of the "advanced" shell features work over ssh (well, that's expected,
since ssh starts a standard bash/zsh/whatever shell on the server)

\- had to install bunch of additional npm deps [2] to make it start on Linux

\- `tmux` is less broken that it used to be when i first tried it, but still
not without any problems, same for `htop` and `vim`

\- it reports that some built-in commands are present, but they don't work at
all (eg. print, source) [3]

Plus it's kinda slow. Terminals are hard.

[0] [https://github.com/vshatskyi/black-
screen/issues/260](https://github.com/vshatskyi/black-screen/issues/260)

[1] [https://github.com/vshatskyi/black-
screen/issues/94](https://github.com/vshatskyi/black-screen/issues/94)

[2] `npm install fs-vacuum init-package-json npm-install-checks npm-registry-
client read-installed`

[3] [https://github.com/vshatskyi/black-
screen/issues/600](https://github.com/vshatskyi/black-screen/issues/600)

~~~
akanet
Yeah, implementing a new terminal emulator (and a custom shell!) is pretty
rough going. I've heard the idea expressed that it's hard to get programmers
to use a new code editor, even if you have a killer feature, because they need
to see every feature that's ever been implemented in every old editor before
they'll switch. Reminiscent of Light Table.

~~~
alexeiz
Those are basic features, not "every feature". Black Screen needs to have
basic features before it can be considered usable. Besides, it's macOS only,
so I won't use it any time soon.

------
seniorsassycat
Here is my quick wish list of features I think I would use at least weekly if
my terminal included them.

\- jump to previous commands.

You just ran a command that printed a few pages, you want to scan from the
first line. You have to scroll up and find the last prompt, where you typed
the command. Why isn't there a shortcut for this?

\- collapse previous outputs (stderr / stdout / both)

Hmmm, were there any warnings in the build I just ran? Anything on stderr? Let
me toggle stdout / stderr after the command has been run.

\- connect a pipe to a previously run command

You run a computation that takes a minute and produces a few pages of output.
You realize you want the output sorted. So you run it again. You could pipe to
sort, or if you piped to a file you could cat the file next time you needed
the output. But why can't you re-use the output that is there in the terminals
scrollback buffer?

~~~
eridius
> _You just ran a command that printed a few pages, you want to scan from the
> first line. You have to scroll up and find the last prompt, where you typed
> the command. Why isn 't there a shortcut for this?_

macOS's Terminal.app has this. Key shortcuts can jump between prompts (or
between marked lines if you want to press a key combo to mark arbitrary
lines), and can also select all text to the previous/next prompt (so you can
trivially copy the output of a command).

> _Hmmm, were there any warnings in the build I just ran? Anything on stderr?
> Let me toggle stdout / stderr after the command has been run._

Potentially interesting, but I'm not sure if it can actually be done. Both
stdout and stderr are connected to the pty; can the pty meaningfully
distinguish which connection is stdout and which is stderr? Also, what happens
if stdout and stderr get mixed in the same line? You can't really collapse
that.

------
infogeek
I thought hyper was supposed to be the terminal for the 21st century, It looks
like another one of "why not make a terminal that takes up hundreds of MB of
ram because we have plenty."

------
Philipp__
I will wait for Alacritty, and will ditch iTerm2 for it. I just need super
minimal and fast terminal with true colors, that's all (although I hope
Alacritty won't go super minimal as they intended to in beginning)

~~~
nkkollaw
Alacritty is so fast. It's amazing.

It has a few problems though, like I keep selecting text by mistake. Also, no
tab support?

At the end of the day, I think iTerm2 is a good balance between speed and
functionality.

~~~
bmon
Alacrity is intended​ to be used with a multiplexer like tmux, at least for
now. I doubt you'll see tab support any time soon, if ever.

~~~
rs86
Shouldn't be any other way. Modularity is such a nice idea. Much nicer than
spinning up something that takes 600 MB of RAM in components not necessary to
completing the task at hand.

Maybe if electron's dependencies could be compiled down to the minimum
functionality needed by a given application this could work.

~~~
RubyPinch
As far as Alacritty is concerned, modularity can easily come with a cost.

once you add in e.g. tmux for multiplexing and scrollback, then you are
bottlenecked at tmux's speeds, as opposed to the terminal emulator's speeds
(not like it really matters, but its an interesting effect)

~~~
Johnny_Brahms
That will be interesting for the tmux (or do we go all the way to nurses??)
developers, because tmux has probably always been way faster than any terminal
emulator it has been running in.

Where will the bottleneck be?

~~~
RubyPinch
I ain't too sure, but

[https://www.reddit.com/r/programming/comments/5mflek/alacrit...](https://www.reddit.com/r/programming/comments/5mflek/alacritty_a_gpuaccelerated_terminal_emulator/dc3r3zc/)
The Terminology (another light-weight term, with memory goals, that has
scrollback) developer's comments are here

------
GreaterFool
IMHO a modern terminal should render things on OpenGL surface. If done well
this should be quite lightweight but at the same time could allow some amazing
rich terminal apps. Something like "give me this 30x10 region and I'm going to
render whatever I want in it"

~~~
z3t4
This sounds cool. Could you elaborate ? Like what is going to render whatever
it wants ?

~~~
wang_li
I could type "df --HISTORY 7 /filesystem" and it renders a graph showing the
last 7 days utilization. Yeah, df would need to change.

Or we could write "thumbnail babes.jpg" and it renders it directly in the
terminal instead of popping up another window.

Or if I'm wanting to do some scripted image editing it'd be pleasant to be
able to render images directly into my terminal as I work out the specifics of
my task. As opposed to writing to temp files and then viewing them with a
separate viewer.

Personally though what I want from a terminal emulator is something
integrating into SSH which creates an out of band channel from the remote end
of my ssh session to the terminal emulator. This way I don't have to play
stupid games with shell prompts and the like, programs could literally know
that a data path to my screen is available and do things like change
background colors if I've changed users. Messing around with prompts and
shoehorning too much stuff into escape sequences is awkward.

~~~
ymse
Terminology can render pictures and video in the terminal and uses OpenGL:

[https://www.enlightenment.org/about-
terminology](https://www.enlightenment.org/about-terminology)

------
KernlPanik
Using Electron to make a terminal emulator is one of the most webshit things
I've ever seen. Congrats

------
dkns
Here's what's been bugging me lately about electron apps. They often take
disproportional amounts of ram compared to what they do/have to offer. Common
response is that it's not an issue because ram is plentiful and even if my
terminal takes 500 mb of ram that's not an issue because I have 8 gb or 16 or
whatever. Yes, but if this trend continues soon we'll end up with electron
based text editor, music player, terminal, 2 - 3 chat apps, git browser, etc.
etc. That starts to quickly add up and I don't feel like buying more ram just
because it's cheap. RAM is cheap but so is a trip to the zoo and given the
choice I'd rather go to zoo than buy more ram.

~~~
realharo
Eventually we may end up with shared system-wide electron instances, that are
shared between all applications that claim they're compatible with said
version. Kind of like Chrome tabs all share the same Chrome browser.

Then someone will come up with ElectronOS.

~~~
Grangar
And then someone will write a web browser for Electron, and then someone will
make that browser headless. Electrons all the way down!

~~~
cdevs
It's going to start with a browser based desktop ('not OS') and trickle down
from there inception style. That way when we build a mirror out of raspberry
pi we can CSS/js the calendar into the desktop background.

------
nkkollaw
Very nice. It's the best-looking terminal I've used, and I do like to use
software that works but also looks good.

However, is considerably slower than iTerm2, which may or may not be a
problem, and might be solved in future versions.

The deal breaker for me to use this version is that tab reordering doesn't
work (doesn't work in Hyper, either).

It would be nice to be able to change the font size.

The real question I have is: why must we use Electron to create good-looking
software? Can't iTerm2's UI be improved and be made to look like Back Screen
or Hyper?

~~~
H4CK3RM4N
What do you mean by good looking though? If it's the color scheme or text
font/size/color those can be customised in practically any terminal
emulator(even Terminal.app).

~~~
nkkollaw
The thing I like the most is the path bar. I also like the design of the space
where you enter commands.

Autocomplete by default is also very nice.

Look & feel is not just colors, but a lot of small details that make the UI
look good and polished.

~~~
Trd
apt install fish

chsh

Now you have those completions, documented and all, in all your terminals,
whether it's Konsole, Gnome-Terminal, St, Terminator or the linux tty.

~~~
nkkollaw
Yes, I've used it in the past.

I don't use it because '&&' is not available. I use it pretty often.

~~~
discreditable
Instead use:

    
    
        command1; and command2
    

More info:
[https://fishshell.com/docs/current/tutorial.html#tut_combine...](https://fishshell.com/docs/current/tutorial.html#tut_combiners)

~~~
nkkollaw
It's not the same thing.

; executes the following command even if the first one fails. && only if the
previous command returns 0.

~~~
Trd
Not when used with and. And and or verify if the previous command executed. It
says as much in the documentation linked by OP.

So you can do things like: runthiscommand; and echo "Success"; or echo
"Failed"

------
coffeedoughnuts
People are bemoaning the use of Electron on this thread quite a lot, for a lot
of different reasons. Rather than just complaining that "Electron == Bad" does
anyone have any thoughts on why Electron is so popular, and how to use that
information to come to a compromise that keeps those benefits without the
inherent negatives of memory usage & speeds issue?

My two pence; A consolidated push of a React Native for Desktop seems like it
could really help here. You get a lot of the benefits of working in a web-like
environment (the developer experience, the development speed, the ability to
share code across runtimes) but you end up with Native Code (Swift, C#, Cpp,
etc.) for each supported OS. RN for Mobile OSs has done wonders in my opinion.
I think a real push for RN in the Desktop could be the next big thing for
desktop apps.

~~~
Chris2048
> and how to use that information to come to a compromise

Electron is popular because it uses regular web tech to build apps. Electron
is slow because it uses regular web tech to build apps.

Where is the compromise?

Another question is "popular with who"..

> the developer experience, the development speed, the ability to share code
> across runtimes

I don't know what you mean by "the developer experience", but surely any high-
level language gets you speedy development, and architectural agnosticism?

~~~
mcbits
A compromise would be to use Electron/Chromium as shared libraries so the bulk
of those apps would be using the same 500 MB - nearly free lunch for users who
would have Chromium running all day either way.

~~~
fasquoika
That basically already exists.[0] The only major issue is that they're limited
to the permissions of normal webpages in the browser.

[0][https://chrome.google.com/webstore/category/apps](https://chrome.google.com/webstore/category/apps)

~~~
mcbits
Chrome apps are being discontinued on most OSes, so they recommend migrating
to Electron or NW.js if a normal web app or extension won't work.
[https://blog.chromium.org/2016/08/from-chrome-apps-to-
web.ht...](https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html)

------
WatchDog
Seems like the polar opposite of the other recent terminal emulator project to
gain my attention Alacritty

------
julianozen
I tried using this in my day to day for a short period of time. If you like
GUI and native apps, it's a dream. If you prefer using things like Sublime or
Kaleidoscope, over vim or the native difftool, Black Screen is what your
workflow has been waiting for. It has native OSX text selection/manipulation,
great (if a little wonky) autocomplete, easier directory browsing, the ability
able to click to add files to git commits, notifications when long processes
finish and several other nice touches.

The typical hacker news user probably isn't going to love this. It's certainly
not as performant, and probably a slower workflow if you're someone that
prefers to never let your hands leave the keyboard.

That being said, it's definitely not ready for full time. I ended up switching
back to terminal for now, but I keep watching this closely.

~~~
tjoff
"If you like GUI and native apps, it's a dream."

Um? If you like native apps you probably despise anything Electron.

~~~
julianozen
Its unideal. Black Screen is certainly rough in the way that Atom was when it
first launched. That being said, it feels more at home next to other OSX app
then terminal which feels more like a window to the 80s

------
em500
I don't care about whether it uses Electron or hundreds of MB or not. I'm just
missing a real motivation for why I would want to use this, rather than the
terminal I'm already using.

Main stated motivations appear to be "better looking" and autocompletion,
which doesn't really sell it to me.

------
vorotato
Call me when it does something a normal terminal doesn't. In the examples I
don't see ANYTHING new.

~~~
Trd
Yeah, those completions that show the documentation is something that shells
like Fish already do out of the box. The terminal is not the right place to do
this to begin with.

------
drinchev
Although I'm not a huge fan of electron as well. I really like the creativity
behind this project.

Btw, there is another electron-based popular emulator called hyper[1].

1: [https://github.com/zeit/hyper](https://github.com/zeit/hyper)

------
irl_
> We aim to be compatible at least with VT100. All the programs (emacs, ssh,
> vim) should work as expected.

At work, I use a VT100 cartridge for my Atari ST. It's not entirely
VT100-compatible but I know for a fact that the vast majority of ncurses
applications (not even to mention tmux) don't work and cause the terminal to
be so corrupted as to be unusable.

Many applications rely on specific behaviours of newer terminals, so a better
target would be xterm (or similar) compatibility. No one is targeting VT100
anymore.

------
ryzawy
The author claims that plugins like vim-airline are "misusing unicode
characters", without an explanation. Can somebody here chime in?

~~~
Nyubis
vim-airline requires you to use a patched font that replaces certain little-
used unicode characters with shapes that airline uses to draw its UI.
Specifically, those < and > looking dividers in the airline statusline.
Although it's totally possible to use airline without this and it will look
only slightly less fancy.

~~~
eridius
They're not little-used unicode characters. They're code points in the Private
Use Area, which is an area of Unicode that's explicitly set aside and will
never be assigned to "real" characters, specifically so they can be used for
custom things. vim-airline's use of the PUA for its custom glyphs is quite
appropriate, it's just annoying that it requires a patched font.

Incidentally, the Apple glyph (, or ⌥⇧K on macOS), is actually in the PUA as
well (in fact, it's the very last PUA codepoint, U+F8FF). Which is why it may
not render correctly in fonts that don't ship on macOS. Anyone reading this on
Windows, Linux, or Android probably won't actually see the apple character.

------
harrygeez
This is actually pretty close to how I envisioned the terminal emulators of
the future will be like. Shame it's based on Electron.

------
azeirah
The major issue with terminal emulators like hyper, is that they don't take
care of all the bazillion tiny edge cases that traditional terminals have had
to deal with over the past.. don't know, 30 years? How do I know that this
thing is stable enough to be a daily driver?

~~~
jazoom
30 years later and many terminals still don't protect against sneaky code
execution, just to give one example. It seems time doesn't fix everything.

~~~
azeirah
No, alright, but I've seen several complaints from people trying out hyper,
and getting exceptions/errors on a daily basis. I can't imagine black screen
being any different, especially because it is newer.

~~~
jazoom
I have hyper installed. I think it's fantastic. The only reason I don't use it
is I usually open a terminal through VS Code but hyper doesn't open in the
correct directory.

------
dvirsky
Looks very nice, however I tried running find that prints a very long list of
files, and the terminal just got stuck after a while. Printing a huge number
of lines without freezing or slowing down is a must for me in a terminal.
Otherwise looks like something I'd use!

------
ageofwant
Also reminds me of this cool thing
[https://github.com/paradoxxxzero/butterfly](https://github.com/paradoxxxzero/butterfly).
Which, I personally have used to amaze and confound.

------
alfa07
It's slow and doesn't scale for my use case (scroll back with 1m lines)

------
Grangar
Looks interesting! I'll be watching this until Windows release.

------
coldtea
> _Black Screen is an IDE in the world of terminals. Strictly speaking, it 's
> both a terminal emulator and an interactive shell based on Electron._

And that's where I closed the page. Though the ideas are nice.

~~~
nkkollaw
Why, though. I don't get it.

~~~
KevanM
Electron is the new devil?

~~~
huhtenberg
It's the new "let's store everything in XML" from the late 90s.

------
oblio
A somewhat related question: is Electron modular? Could you build it without
sound support, for example?

------
HalfwayToDice
Enough about RAM and CPU. Let's talk about BATTERY LIFE.

Why would I run a terminal app which drains my Macbook battery three times as
fast as the default app?

------
rrggrr
This is AWESOME. The type ahead support is terrific.

------
jaimehrubiks
And there it comes the anti-electron army, prepare your shield.

~~~
bmon
While I don't like seeing people flame op for making a choice of technology,
electron boils down to a trade-off between the developer's convenience and the
end user's computing power. I think it's pretty reasonable for the users to
not like that prospect.

~~~
matt4077
The developer's convenience is directly reflected in pace of development and
accessibility for plugin developers, both of which users care about.

~~~
Chris2048
but it's short-term convenience, for a developer mostly familiar with web-
tech.

