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

21–30 of 159 posts

Re: State of the Terminal

#21

Post by hnlmorg »

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…

The problem is to break away from ANSI escape sequences and the like means also rewriting 50 years of command line tools.

Like with the modern web, there’s just too much momentum behind the current design to make it practical to reinvent it from scratch

That doesn’t mean that things cannot improve though. It just makes it massively more difficult if you want to retain backwards compatibility. And if you don’t, then people probably won’t adopt it because they won’t be able to get their job done, regardless of how good the UX is.

As it happens, I am trying to solve these problems. In part with my alternative shell. To take your SO example, I’ve recently even playing around with integrating ChatGPT to help with hints (on top of automatic man page parsing which already happens).

I’m also writing a new terminal emulator that aims to bring interactive widgets (like support for sorting and filling anything that looks like a table). But that term is very much alpha at the moment.

Re: State of the Terminal

#22

Post by geor9e »

ranger_danger wrote: post #18
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 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.

Re: State of the Terminal

#23

Post by bongobingo1 »

ranger_danger wrote: post #18
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 do you suggest?

Maybe some kind of subscription service?

Re: State of the Terminal

#24

Post by tristan957 »

blueflow wrote: post #7
eminence32 wrote: post #3

A quick off-the-cuff remark based solely on the title: in 2024, I think the state of the terminal has never been better, in large part to Microsoft making a high quality terminal easily available to everyone on Windows [1] As an application author, I love being able to assume that all major platforms have a good terminal and that my favorite terminal rendering libraries should Just Work on all of them [1] https://git…

I really dislike that they re-used the TERM value from xterm instead of getting their own merged into terminfo. And then not documenting which sequences are actually supported and which aren't.

You would be surprised how much software is built exclusively for TERM=xterm or TERM=xterm-*.

Re: State of the Terminal

#25

Post by dartos »

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…

There is an effort, but it’s mostly built on cruft (which libraries like ncurses or the projects at charm.sh try abstracting away)

Also, what would we use besides escape sequences? They are about as small as can be for what they do.

Terminals deal with streams of bytes. They don’t just download entire views and render them (normally.) This normally works to their advantage.

There’s also the ansi standard control sequences, which imo should have more focus on them as opposed to the terminfo db.

Re: State of the Terminal

#26

Post by eej71 »

eminence32 wrote: post #3

A quick off-the-cuff remark based solely on the title: in 2024, I think the state of the terminal has never been better, in large part to Microsoft making a high quality terminal easily available to everyone on Windows [1] As an application author, I love being able to assume that all major platforms have a good terminal and that my favorite terminal rendering libraries should Just Work on all of them [1] https://git…

I mainly use microsoft terminal now just beacuse it did a better job handling more of the font decorations (italic was one that I recall). My one gripe though is that it seems like microsoft terminal is still kind of slow at scrolling. If I accidentally grep for something that spews a lot to the screen, terminal is just plain hung up a bit. And for many of us - but not everyone? - control-space in emacs is just kind of broken. Long standing open issue for that one.

Re: State of the Terminal

#28

Post by blueflow »

ranger_danger wrote: post #20
blueflow wrote: post #7

Earlier quoted context omitted.

I really dislike that they re-used the TERM value from xterm instead of getting their own merged into terminfo. And then not documenting which sequences are actually supported and which aren't.

They have their own, and it's documented. https://invisible-island.net/ncurses/terminfo.src.html#tic-m... Surely you can imagine that it takes years or more to get people to update though, so switching to a new entry right away could make for a bad user experience.

That's not made by them and not supported by upstream, see full thread: https://lists.gnu.org/archive/html/bug-ncurses/2019-08/msg00...

Re: State of the Terminal

#29

Post by dartos »

tristan957 wrote: post #24
blueflow wrote: post #7

Earlier quoted context omitted.

I really dislike that they re-used the TERM value from xterm instead of getting their own merged into terminfo. And then not documenting which sequences are actually supported and which aren't.

You would be surprised how much software is built exclusively for TERM=xterm or TERM=xterm-*.

Which is exactly the root cause of terminal weirdness.

Instead of a standard, we have mountains of terminfo entries which are mostly slight xterm variants and ancient hardware

Re: State of the Terminal

#30

Post by dartos »

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…

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