8 ms·

Are there any efforts to radically reimagine the entire "terminal" concept? Seems very limiting to advance further in the 21st century with those same 70's tech

Are there any efforts to radically reimagine the entire "terminal" concept? Seems very limiting to advance further in the 21st century with those same 70's technical assumptions. [edit] I was thinking more in terms of being unconstrained by low-res displays, inability to display anything other than text, etc.

ranger_danger 2y ago
What do you suggest?
- geor9e 2y ago
  Different person here, but I wish there was a terminal where mouse clicks moved the text cursor (without holding any hotkey), mouse drags selected text and typing replaced the selected text, ctrl-A selected the entire current command (all the text after $ ), holding left/right arrow went WAY faster… Basically, if you know how to competently edit an email, you shouldn't struggle in frustration at editing a big terminal command. I believe that some day there will be a terminal app you can sit a kid down in front of, and they're be able to fix a typo without any frustration or special knowledge. That day hasn't yet come. I get the historical traditions for why terminal is the way it is, and I get why people who already know the secrets don't care to change it, but IMO it's time to move on.
  - dartos 2y ago
    Some terminals support mouse input without any special modifier keys. I’ve used vim in iterm doing exactly that.
  - joouha 2y ago
    It's up to individual applications how they implement user input. All of this is entirely possible in modern terminal emulators - look at the micro text editor, for example. I guess most shells (bash, zsh, etc.) keep things "traditional" for backwards compatibility reasons.
  - UI_at_80x24 2y ago
    >Different person here, but I wish there was a terminal where mouse clicks moved the text cursor (without holding any hotkey) Umm, This is a `feature` in Konsole that I ___HATE___. I'd have a file open in vim that I'm editing. I'd also have a browser window open and I'm trying to copy text over to my terminal. Well, wherever you click in the terminal window to 'activate' it for pasting, causes the active line to jump to that place regardless of where your cursor was before. IT'S HORRIBLE!! I'd much rather click on the window, then ctrl-v to paste my clipboard. Now I have to be extra careful and just click on the windows decoration/header, or frame. This has caused me dozens of missed-pastes.
    - fiddlerwoaroof 2y ago
      For vim it’s something like :set nomouse to disable this. I go out of my way to disable mouse control in the terminal too
  - yjftsjthsd-h 2y ago
    > Basically, if you know how to competently edit an email, you shouldn't struggle in frustration at editing a big terminal command. I believe that some day there will be a terminal app you can sit a kid down in front of, and they're be able to fix a typo without any frustration or special knowledge. That day hasn't yet come. In BASH, set $EDITOR to whatever you want - even a GUI editor - and then hit (by default) ctrl-x ctrl-e and it'll open the current line in your editor and when you save+close the editor the command will run. https://unix.stackexchange.com/questions/85391/where-is-the-bash-feature-to-open-a-command-in-editor-documented https://unix.stackexchange.com/questions/85391/where-is-the-... seems like a decent discussion of the feature, and its footguns (it does execute whatever was in the buffer when you close the editor without confirmation), and even some talk of how to improve it a bit.
    - ranger_danger 2y ago
      > without holding any hotkey
- bongobingo1 2y ago
  Maybe some kind of subscription service?
  - tristan957 2y ago
    https://www.warp.dev/ https://www.warp.dev/
    - smm11 2y ago
      I'd be all over that if it didn't phone home for some reason.
  - Vegenoid 2y ago
    I think you're on to something, maybe let's put AI in it too? Oh, someone beat us to the punch... https://www.warp.dev/ https://www.warp.dev/
dartos 2y ago
What assumptions specifically? Terminals, at the protocol level, assume nothing. It’s just streams of bytes which are processed then rendered. The protocol makes no technical assumptions, which is why it has both lived so long and is such a mess
- Bjartr 2y ago
  One assumption is that it's one stream of bytes (Okay, two if you count stderr) and so control and metadata has to be interleaved with content to be displayed
  - dartos 2y ago
    I think that it’s a feature of the protocol that it’s stream based. It allows for a fairly responsive interface even in rough network conditions.
    - Bjartr 2y ago
      No reason the transmission protocol and the application/ui protocol need to be coupled in their level of abstraction. You could send the same data plus just enough bytes to know which data goes with which stream, then a terminal app could see a content stream and a control stream. I'm not spec-ing out a concrete protocol design here, just mentioning it is a fundamental assumption that leads to much of the (lack of) ergonomics in the current approach. Namely the interleaving of control characters and display characters. Any additional functionality we want needing to be squeezed down into that representation makes doing so cumbersome.
      - dartos 2y ago
        > No reason the transmission protocol and the application/ui protocol need to be coupled in their level of abstraction They aren’t as there isn’t any application protocol. Ncurses is the closest you’ll get. But several TUI frameworks exist (like ncurses and the charm.sh packages) which abstract the low level let’s call it a wire protocol
red_admiral 2y ago
There have been many unsuccessful such efforts. I'm only half joking if I say "the web" has been the most successful one to date. Or maybe "the browser window" is more precise, here. The terminal is an odd, but historically understandable, mix of an API and a user interface, with the added UNIX flavor of "if everything communicates through text streams, then everything can talk to everything else" - which includes both humans and other programs. The clean way to go these days is of course to separate the two out (though on the terminal, arguably a REST endpoint is a also kind of user interface). Powershell is a candidate for the "terminal reimagined" award in the sense that you're passing around structured objects rather than text streams internally, and so avoiding a lot of escaping/injection badness, even though the UI is a terminal window (but with a lot more autocomplete etc. features). (Personally, I hate its syntax, but that's a matter of style.) The moment you want to go down the "UI reimagined" route while keeping as much cross-platform compatibility as possible, you end up with HTML/CSS and the layer of your choice on top of JS.
mixmastamyk 2y ago
A few have kicked the tires but the fact you’d have to “boil the oceans” and rewrite every program and script in existence makes it a huge amount of work. You’d most likely have to maintain backwards compatibility also, so you’d just create N+1 complexity, rather than simplifying things.
MisterTea 2y ago
Plan 9 dropped the concept and went graphics first using a 2D engine called devdraw which you load assets into and issue draw commands. Text is a first class primitive so drawing text is pretty simple. It has a shell but it lacks cursor control so stdout/stderr is written to the window's /dev/text - think of a window as a dumb textbox. If you need vt100 emulation you run the command in vt(1) which is a graphics program which emulates a tty terminal. When you run a graphical program from the shell it opens in the same window as it should because the window is more like a canvas. The window manager Rio(1) just multiplexes the /dev/draw device so you can run any graphical program from the initial graphical terminal - a window manager not needed. You can also run rio in rio as much as you want - its devdraw all the way down. If you really wanted to preserve a TUI program you could run in vt(1) or I think there is a curses library that does draw stuff on the back end skipping the vt emulation. In this day and age I see no reason to perpetuate the tty terminal outside of Unix as it's an obsolete concept.
- theamk 2y ago
  that sounds like a replacement for X11/Wayland, not for the terminal. and this of course sounds fine and nice, until you need to interop with other machines / OS-es - in which case you open vt and ssh to whatever location. Or you want your application to be callable by other machine (or via ssh or from script or cron...) - in which case you eschew all the draw commands and do good old print. And now we are back to where Unix is.
pjmlp 2y ago
Yes, back at ETHZ, Xerox, TI, Genera,.... The terminal is a full graphics REPL, working in tandem with the mouse, and the languages have full access across the whole OS stack. Even if its syntax is not loved by everyone, Powershell is the closest we have to it.
albertzeyer 2y ago
There have been many. But none of them really successful, in the sense that they were more proof-of-concept, never fully feature-complete, or just not adopted by the community. See the list here: https://github.com/hoeck/schirm https://github.com/hoeck/schirm I think the most popular was TermKit (https://github.com/unconed/TermKit https://github.com/unconed/TermKit, https://news.ycombinator.com/item?id=30517205 https://news.ycombinator.com/item?id=30517205). Maybe the most successful such attempts is DomTerm (https://domterm.org https://domterm.org).
bitcompost 2y ago
You might be interested in Arcan desktop engine ( https://arcan-fe.com https://arcan-fe.com ), which has a tui api for clients. It has been used to build an interesting experimental shell: https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lashcat9/ https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lash...

ranger_danger 2y ago

What do you suggest?

geor9e 2y ago
Different person here, but I wish there was a terminal where mouse clicks moved the text cursor (without holding any hotkey), mouse drags selected text and typing replaced the selected text, ctrl-A selected the entire current command (all the text after $ ), holding left/right arrow went WAY faster… Basically, if you know how to competently edit an email, you shouldn't struggle in frustration at editing a big terminal command. I believe that some day there will be a terminal app you can sit a kid down in front of, and they're be able to fix a typo without any frustration or special knowledge. That day hasn't yet come. I get the historical traditions for why terminal is the way it is, and I get why people who already know the secrets don't care to change it, but IMO it's time to move on.
- dartos 2y ago
  Some terminals support mouse input without any special modifier keys. I’ve used vim in iterm doing exactly that.
- joouha 2y ago
  It's up to individual applications how they implement user input. All of this is entirely possible in modern terminal emulators - look at the micro text editor, for example. I guess most shells (bash, zsh, etc.) keep things "traditional" for backwards compatibility reasons.
- UI_at_80x24 2y ago
  >Different person here, but I wish there was a terminal where mouse clicks moved the text cursor (without holding any hotkey) Umm, This is a `feature` in Konsole that I ___HATE___. I'd have a file open in vim that I'm editing. I'd also have a browser window open and I'm trying to copy text over to my terminal. Well, wherever you click in the terminal window to 'activate' it for pasting, causes the active line to jump to that place regardless of where your cursor was before. IT'S HORRIBLE!! I'd much rather click on the window, then ctrl-v to paste my clipboard. Now I have to be extra careful and just click on the windows decoration/header, or frame. This has caused me dozens of missed-pastes.
  - fiddlerwoaroof 2y ago
    For vim it’s something like :set nomouse to disable this. I go out of my way to disable mouse control in the terminal too
- yjftsjthsd-h 2y ago
  > Basically, if you know how to competently edit an email, you shouldn't struggle in frustration at editing a big terminal command. I believe that some day there will be a terminal app you can sit a kid down in front of, and they're be able to fix a typo without any frustration or special knowledge. That day hasn't yet come. In BASH, set $EDITOR to whatever you want - even a GUI editor - and then hit (by default) ctrl-x ctrl-e and it'll open the current line in your editor and when you save+close the editor the command will run. https://unix.stackexchange.com/questions/85391/where-is-the-bash-feature-to-open-a-command-in-editor-documented https://unix.stackexchange.com/questions/85391/where-is-the-... seems like a decent discussion of the feature, and its footguns (it does execute whatever was in the buffer when you close the editor without confirmation), and even some talk of how to improve it a bit.
  - ranger_danger 2y ago
    > without holding any hotkey
bongobingo1 2y ago
Maybe some kind of subscription service?
- tristan957 2y ago
  https://www.warp.dev/ https://www.warp.dev/
  - smm11 2y ago
    I'd be all over that if it didn't phone home for some reason.
- Vegenoid 2y ago
  I think you're on to something, maybe let's put AI in it too? Oh, someone beat us to the punch... https://www.warp.dev/ https://www.warp.dev/

dartos 2y ago

What assumptions specifically? Terminals, at the protocol level, assume nothing. It’s just streams of bytes which are processed then rendered. The protocol makes no technical assumptions, which is why it has both lived so long and is such a mess

Bjartr 2y ago
One assumption is that it's one stream of bytes (Okay, two if you count stderr) and so control and metadata has to be interleaved with content to be displayed
- dartos 2y ago
  I think that it’s a feature of the protocol that it’s stream based. It allows for a fairly responsive interface even in rough network conditions.
  - Bjartr 2y ago
    No reason the transmission protocol and the application/ui protocol need to be coupled in their level of abstraction. You could send the same data plus just enough bytes to know which data goes with which stream, then a terminal app could see a content stream and a control stream. I'm not spec-ing out a concrete protocol design here, just mentioning it is a fundamental assumption that leads to much of the (lack of) ergonomics in the current approach. Namely the interleaving of control characters and display characters. Any additional functionality we want needing to be squeezed down into that representation makes doing so cumbersome.
    - dartos 2y ago
      > No reason the transmission protocol and the application/ui protocol need to be coupled in their level of abstraction They aren’t as there isn’t any application protocol. Ncurses is the closest you’ll get. But several TUI frameworks exist (like ncurses and the charm.sh packages) which abstract the low level let’s call it a wire protocol

red_admiral 2y ago

There have been many unsuccessful such efforts. I'm only half joking if I say "the web" has been the most successful one to date. Or maybe "the browser window" is more precise, here. The terminal is an odd, but historically understandable, mix of an API and a user interface, with the added UNIX flavor of "if everything communicates through text streams, then everything can talk to everything else" - which includes both humans and other programs. The clean way to go these days is of course to separate the two out (though on the terminal, arguably a REST endpoint is a also kind of user interface). Powershell is a candidate for the "terminal reimagined" award in the sense that you're passing around structured objects rather than text streams internally, and so avoiding a lot of escaping/injection badness, even though the UI is a terminal window (but with a lot more autocomplete etc. features). (Personally, I hate its syntax, but that's a matter of style.) The moment you want to go down the "UI reimagined" route while keeping as much cross-platform compatibility as possible, you end up with HTML/CSS and the layer of your choice on top of JS.

mixmastamyk 2y ago

A few have kicked the tires but the fact you’d have to “boil the oceans” and rewrite every program and script in existence makes it a huge amount of work. You’d most likely have to maintain backwards compatibility also, so you’d just create N+1 complexity, rather than simplifying things.

MisterTea 2y ago

Plan 9 dropped the concept and went graphics first using a 2D engine called devdraw which you load assets into and issue draw commands. Text is a first class primitive so drawing text is pretty simple. It has a shell but it lacks cursor control so stdout/stderr is written to the window's /dev/text - think of a window as a dumb textbox. If you need vt100 emulation you run the command in vt(1) which is a graphics program which emulates a tty terminal. When you run a graphical program from the shell it opens in the same window as it should because the window is more like a canvas. The window manager Rio(1) just multiplexes the /dev/draw device so you can run any graphical program from the initial graphical terminal - a window manager not needed. You can also run rio in rio as much as you want - its devdraw all the way down. If you really wanted to preserve a TUI program you could run in vt(1) or I think there is a curses library that does draw stuff on the back end skipping the vt emulation. In this day and age I see no reason to perpetuate the tty terminal outside of Unix as it's an obsolete concept.

theamk 2y ago
that sounds like a replacement for X11/Wayland, not for the terminal. and this of course sounds fine and nice, until you need to interop with other machines / OS-es - in which case you open vt and ssh to whatever location. Or you want your application to be callable by other machine (or via ssh or from script or cron...) - in which case you eschew all the draw commands and do good old print. And now we are back to where Unix is.

pjmlp 2y ago

Yes, back at ETHZ, Xerox, TI, Genera,.... The terminal is a full graphics REPL, working in tandem with the mouse, and the languages have full access across the whole OS stack. Even if its syntax is not loved by everyone, Powershell is the closest we have to it.

albertzeyer 2y ago

There have been many. But none of them really successful, in the sense that they were more proof-of-concept, never fully feature-complete, or just not adopted by the community. See the list here: https://github.com/hoeck/schirm https://github.com/hoeck/schirm I think the most popular was TermKit (https://github.com/unconed/TermKit https://github.com/unconed/TermKit, https://news.ycombinator.com/item?id=30517205 https://news.ycombinator.com/item?id=30517205). Maybe the most successful such attempts is DomTerm (https://domterm.org https://domterm.org).

bitcompost 2y ago

You might be interested in Arcan desktop engine ( https://arcan-fe.com https://arcan-fe.com ), which has a tui api for clients. It has been used to build an interesting experimental shell: https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lashcat9/ https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lash...