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
The Dawn of a New Command Line Interface (2017)
11–18 of 18 posts
Re: The Dawn of a New Command Line Interface (2017)
#12I 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?
I would expect it to be possible already, given that imgcat is a thing
Re: The Dawn of a New Command Line Interface (2017)
#13I 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?
Re: The Dawn of a New Command Line Interface (2017)
#14The 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.
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.
Re: The Dawn of a New Command Line Interface (2017)
#15Those who don't understand Unix are condemned to reinvent it, poorly.
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.
Re: The Dawn of a New Command Line Interface (2017)
#16The 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.
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…
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.
Re: The Dawn of a New Command Line Interface (2017)
#17Those who don't understand Unix are condemned to reinvent it, poorly.
> Confusion between user-input and data – programs can’t reliably distinguish between interactive (keyboard) input, pasted/”IPC” input and other forms of data entry.
No! This is a feature. The actual core data-processing part of a program should not care where its data comes from. There needs to be separation between engine and interface, and different interfaces are needed for different types of input scenarios.
Re: The Dawn of a New Command Line Interface (2017)
#18The 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.
>abstracting away from visual distraction is the very point of terminals in the first place. Um, no. Text terminals are a natural outgrowth of how telecommunications has worked from the start. It's easy to trace their evolution starting from the first telegraph and radio messages that used morse code to send messages... the information is written onto a paper page line by line to replicate the original message writte…
> The command line wasn't invented to provide a distraction free environment, it was literally the only thing available
You miss the point. It's not important why it was invented, what's important is why it continues to be popular in 2019.