
The Dawn of a New Command Line Interface (2017) - commons-tragedy
https://arcan-fe.com/2017/07/12/the-dawn-of-a-new-command-line-interface/
======
m4r35n357
Those who don't understand Unix are condemned to reinvent it, poorly.

~~~
Pete_D
I'd agree in general, but why think that the Arcan dev doesn't understand
Unix? There's nothing in the Unix philosophy that says we have to wed
ourselves to the specific weirdnesses of old DEC terminals forever.

------
hos234
I have been looking for something like jupyter notebooks or matplotlib
interactive mode that works in the terminal. Meaning I type in a command and
if output is an image or video or interactive graph it shows up in the
terminal itself. How much time would it take to create something like that
with arcan? Or something like that already available?

~~~
7thaccount
Wolfram Mathematica is what Jupyter Notebooks probably came from. Their
notebooks allow you to do all sorts of command line stuff as well as neural
nets, image processing, graphs, 3D image visualization, optimization, symbolic
math, natural language parsing ..etc. It also has a command line shell.

Unfortunately, it is commercial, closed source, and not exactly cheap. The
language is nice for a lot of things (kind of lisp like) though and although I
love open source languages and tools, Mathematica is really impressive.

------
wolfspider
I think in order to understand this properly you have to build and try out
Arcan for yourself. It took me a little while to understand the LuaJIT
application structure but without that in mind this seems like- "a terminal
with graphics attached" which it most certainly is not. This is more of a
solution to the vast amount of protocols used to shovel data to the user in
the UI message pump in a fairly static way. Shmif allows sharing this data
between apps without all the translation, stubs, and overhead that normally
comes with the territory:
[https://github.com/letoram/arcan/wiki/Shmif](https://github.com/letoram/arcan/wiki/Shmif)

------
otabdeveloper4
The idea of "let's show pictures directly in the terminal" is as old as
terminals themselves.

It never works, because abstracting away from visual distraction is the very
point of terminals in the first place.

~~~
MisterTea
It doesn't work because it breaks the concept of an addressable grid of cursor
positions for individual fixed fonts. How do you mix bitmaps in cleanly?

Plan 9 did away with that dichotomy by making it graphical first called
/dev/draw. A console device, /dev/cons, handles textual i/o and renders it to
the /dev/draw device. You can bypass that and open /dev/draw and render your
own text using the same library /dev/cons uses. If one needs a unix compatible
virtual terminal with addressable cursor and proper copy/paste then the vt
program is used. vt then opens /dev/cons and interprets shell escape sequences
written by the program and pokes at the /dev/cons buffer. So the rc shell in
plan 9 doesn't do escapes or colors or anything. It just reads and interprets
commands from stdin and writes its output to stdout in the most simplistic
manner possible. pretty much a serial console that keeps scrolling. There is
no cursor.

~~~
MisterTea
Just realized I made a mistake, vt doesn't write text to cons, it renders the
text itself though grabs keyboard input from cons. It's a graphical program in
that sense as it has to also handle color text in xterm mode in addition to
providing an addressable cursor.

