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

71–80 of 159 posts

Re: State of the Terminal

#71

Post by hiccuphippo »

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.

Sounds like the user agent string in web browsers.

Re: State of the Terminal

#72

Post by yjftsjthsd-h »

bmitc wrote: post #62
hnlmorg wrote: post #21

Earlier quoted context omitted.

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

> The problem is to break away from ANSI escape sequences and the like means also rewriting 50 years of command line tools. Are we really that reliant on those command line tools? I only use a handful of them, and any time it gets more complicated, I reach for a real programming language to do the scripting. Those tools just do a bunch of string parsing, and the user interfaces are usually incredibly esoteric, incons…

In a word: Yes.

The long tail is very long, and it's not just the bare text tools, it's the bare text tools (including tools that were written 30 years ago and that haven't changed since, and the tools that barely even count as cli tools), and also anything that ever did anything more interesting. You're not just talking about rewriting coreutils, you're also talking about redoing vim and emacs and top and all the *stat programs and tmux and screen and ...

Re: State of the Terminal

#73

Post by 9dev »

Borg3 wrote: post #32
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…

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

I have to use it. That's the point. The CLI is an important and great piece of technology; I just don't love the way things are, and would prefer to see them improved instead.

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

This is not how stuff like that works. Terminal interfaces are an ecosystem; there are a lot of different projects attempting new approaches, but there's no shared sense of the existing problems—as proved by your comment. I've written my original comment to make more people aware of those issues, increasing awareness.

> 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, it's everywhere so I can run stuff on platforms that problem existed before you were even born.

I didn't argue for that; in fact, I didn't even argue for removing the existing legacy stuff. Maybe try reading the original comment again? Just because we have a working solution doesn't mean we should stop innovating. There are tons of UX improvements possible beyond rendering emojis, such as proper inter-process message passing via standardised interfaces- just imagine piping from `ls` to any other process, and have that process know that it just got a list of file references, instead of a bunch of characters (Powershell does something similar). Let terminals offer completions like IDEs do. Let them render proper progress bars, without abusing braille characters. There's so many things people do just because they did them like this since forever, they stop questioning if there isn't a better way.

Re: State of the Terminal

#74

Post by hiccuphippo »

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…

Does this mean I can run the Build Your Own Text Editor[0] tutorial in Windows without WSL? I did it in Linux a few years ago, recently heard of Crossterm[1] and was thinking trying to remake it with that, but maybe it's not necessary?

[0] https://viewsourcecode.org/snaptoken/kilo/

[1] https://github.com/crossterm-rs/crossterm

Re: State of the Terminal

#75

Post by orangecat »

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…

tooling shouldn't need to parse strings to do something useful; and junior developers shouldn't need to waste hours scrolling an obtuse man page until they resort to a half-assed SO response

Absolutely. Glad we fixed all that with CSS...

Re: State of the Terminal

#76

Post by mandibles »

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…

While we're at it, can we get rid of staggered keyboards? We don't need to accommodate mechanical linkages from the bottom rows any longer, yet here we are.

As other commenters have pointed out, once conventions and standards have been adopted, there is almost no way of dislodging them. It's a coordination problem. New standards and approaches usually need to be at least a 10x improvement over the status quo in order to be adopted organically.

The same story applies to all areas of human endeavor.

Re: State of the Terminal

#77

Post by thibran »

I love the abstract idea of the command-line, but not it's textual implementation. The best currently available old school shell is Nushell IMHO.

What I really want is a GUI that works like a command-line, but with rich media and mouse support. Instead of 100% key input I would sometimes like to click and add/remove/filter data.

The terminal is so useful, still it's strange we tolerate up to this day all it's shortcomings.

Re: State of the Terminal

#78

Post by joouha »

yjftsjthsd-h wrote: post #70
joouha wrote: post #16

Do any terminals support overprinting? This could radically change what is possible in TUIs

I don't know about overprinting per se, but you can already use whatever foreground+background colors you want; how much benefit would overprinting be?

This would allow more complex shapes to be drawn by combining multiple glyphs, which would be useful for complex TUI applications (there are only a limited number of box-drawing characters available) Also, this could allow drawing more than two colours per terminal cell.

Re: State of the Terminal

#79

Post by eminence32 »

hiccuphippo wrote: post #74
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…

Does this mean I can run the Build Your Own Text Editor[0] tutorial in Windows without WSL? I did it in Linux a few years ago, recently heard of Crossterm[1] and was thinking trying to remake it with that, but maybe it's not necessary? [0] https://viewsourcecode.org/snaptoken/kilo/ [1] https://github.com/crossterm-rs/crossterm

Crossterm does indeed work well under Windows Terminal. I use it indirectly via the ratatui library[1]

[1] https://github.com/ratatui-org/ratatui

Re: State of the Terminal

#80

Post by 9dev »

mandibles wrote: post #76
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…

While we're at it, can we get rid of staggered keyboards? We don't need to accommodate mechanical linkages from the bottom rows any longer, yet here we are. As other commenters have pointed out, once conventions and standards have been adopted, there is almost no way of dislodging them. It's a coordination problem. New standards and approaches usually need to be at least a 10x improvement over the status quo in order…

Im not so sure. We have HTTP3 now, which is binary. We use different image formats than we used to, and switched from horses to cars, too. Why shouldn’t we be able to innovate in this space? Building new walls doesn’t automatically imply tearing old ones down.
Post reply on HN