The Dawn of a New Command Line Interface (2017)

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?

Those who don't understand Unix are condemned to reinvent it, poorly.

>Meaning I type in a command and if output is an image or video or interactive graph it shows up in the terminal itself.

I'd go one step further:

Give me a full 3D context (like games use) that can handle text, image, video, 3D model rendering, and VR workspaces, with the command line as the basic mode.

I disagree. The reason it doesn't work is because:

- there are so many different standards that terminal emulators adhere to that it makes it practically impossible to write anything that works reliably

- and you need backwards compatibility which means you can't easily break away and create a new CLI framework designed to progress CLIs into the next century.

The fact that ncurses and other terminal UIs have been so prevalent demonstrates that "visual distraction" is sometimes beneficial in a terminal. So much so that some people's tmux sessions could be mistaken for tiling window managers. But unfortunately the terminal is still ostensibly the same 1960s protocol.

>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 written by hand.

It's a natural outgrowth from that to have the machine translate back to a line of text. When it's time to print the next line, it makes sense to unroll the next part of the scroll (scroll down) rather than start your decoding by unrolling all of the available scroll paper.. that makes a mess, and tends to lead to loss of data.

Early computer TTY (teletype) terminals used roll and fanfold paper to print incoming characters. You could use them for editing despite not having an addressable cursor. Some editors of the time would support using a printing terminal for editing by working on a line by line basis. Unix supports editing on the command line with sed and ed.

It's a natural transition from the line by line printing on paper to a CRT display... you just print each line starting at the top of the screen, display as much stuff as you can, and when the screen is full you get rid of the oldest information (the top line) and print the new line in the space at the bottom. Just like using the paper scroll, except instead of having a bunch of already printed paper hanging around, there's nothing... much neater.

From that, the idea of editing using an addressable cursor comes quickly, leading to the text terminal apps we all use today (which used to be hardware based.. a keyboard/screen arrangement that couldn't run programs and in some cases wasn't digital).

The command line wasn't invented to provide a distraction free environment, it was literally the only thing available, and it's still an optimal way to get certain workflows done over and above GUI based systems.

It also remains a natural way to do programming because almost all programming happens via computer languages rather than visual systems.