Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of the Terminal

gpanders.com

Post reply on HN
Print view View original

31–40 of 159 posts

Re: State of the Terminal

#31

Post by dartos »

lambdaba wrote: post #14

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.

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

Re: State of the Terminal

#32

Post by Borg3 »

9dev wrote: post #17

I could never really understand the enthusiasm. Why are we still dealing with over half a century of cruft? I get that this is a core piece of technology lots of stuff is built upon, and I'm not arguing to get rid of the classic terminal emulation altogether. But I wish there was an effort of building a new, modern, textual interface to computers with modern assumptions and integration bindings. We shouldn't need to…

First, dont like it? Dont use it. No need to cry over it.

Second, dont like it? Write something better, do show case and maybe people like it and start using it.

Third, not everyone needs to use 100s of MB of memory to render some idiotic emoji along the text using GPU accelerated routines. Those old legacy stuff is lightweight, its everywhere so I can run stuff on platforms that problem existed before you were even born.

I myself love CLI. Its reliable, easy to use, fast!! interface. I cant really imagine a computer without CLI.. Its like? WTF? :)

Re: State of the Terminal

#33

Post by red_admiral »

lambdaba wrote: post #14

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.

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.

Re: State of the Terminal

#34

Post by kergonath »

ilaksh wrote: post #9

It would be nice if more terminals other than xterm would support Tektronix vector graphics. https://github.com/bennetyee/TekGraphics Here's an emulator for those specific real terminals: https://github.com/rricharz/Tek4010

I don’t really want vector graphics, but more support for sixels would be massively helpful.

Re: State of the Terminal

#35

Post by mixmastamyk »

lambdaba wrote: post #14

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.

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.

Re: State of the Terminal

#37

Post by mixmastamyk »

jprete wrote: post #11
_lvbh wrote: post #4

> Modifier keys like Ctrl and Alt complicate this situation. This is such an understatement. Alacritty required you to manually bind keys to control characters in the config and finding the control characters escape sequences were such a nightmare I gave up and switched to foot

The wonkiness of modifier keys is a constant barrier whenever I try to do anything to make a terminal environment more ergonomic. In the end I always go back to 100% IDEs and GUI document editors.

Looks like VTE finally fixed their bug regarding Ctrl+arrows etc. I have few issues now.

Re: State of the Terminal

#38

Post by joouha »

geor9e wrote: post #22
ranger_danger wrote: post #18

Earlier quoted context omitted.

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 termina…

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.

Re: State of the Terminal

#39

Post by MisterTea »

lambdaba wrote: post #14

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.

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.

Re: State of the Terminal

#40

Post by albertzeyer »

I really would like to have:

* text folding (https://gitlab.freedesktop.org/terminal-wg/specifications/-/..., https://stackoverflow.com/questions/52812618/ansi-escape-seq...)

* graphics (https://gitlab.freedesktop.org/terminal-wg/specifications/-/...)

I wonder a bit why all those next-gen (often HTML-based) terminal attempts have not been successful (e.g. TermKit: https://news.ycombinator.com/item?id=30517205). Probably because SSH/Mosh/Tmux concepts are difficult to take over there, and those are somewhat crucial. And text folding or graphics also would have issues w.r.t. those (see also the linked discussions).

DomTerm (https://domterm.org) supports both those features, but it does not work with Mosh+Tmux, which is my main use case.

Post reply on HN