Hacker News Reader

Comment by lambdaba | Hacker News Reader

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.

View on HN

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.

You might be interested in Arcan desktop engine ( 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-lash...

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.

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.

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.

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

I think the most popular was TermKit (https://github.com/unconed/TermKit, https://news.ycombinator.com/item?id=30517205).

Maybe the most successful such attempts is DomTerm (https://domterm.org).

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

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

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.

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.

> 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

I know there isn't any. The topic is what innovations are possible. One possible innovation is to create such a protocol.

Sure, but I’m arguing that replacing the very minimal protocol with a heavier one would not be an innovation nor would it be useful at all as you would always need some kind of low level streaming protocol, unless you’re looking to replace pretty much all of Unix land, but that’s a whole different discussion.

I don't see why the mere existence of lower level transport details must preclude discussion of higher level developer ergonomics.

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.

What do you suggest?

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.

Some terminals support mouse input without any special modifier keys. I’ve used vim in iterm doing exactly that.

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.

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

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

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

> without holding any hotkey

Maybe some kind of subscription service?

https://www.warp.dev/

I'd be all over that if it didn't phone home for some reason.

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/

Reply on news.ycombinator.com