4 ms·

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

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.

hnlmorg 7y ago
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.
Accujack 7y ago
>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.
- otabdeveloper4 7y ago
  > 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.
MisterTea 7y ago
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 7y ago
  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.

hnlmorg 7y ago

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.

Accujack 7y ago

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

otabdeveloper4 7y ago
> 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.

MisterTea 7y ago

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