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

131–140 of 159 posts

Re: State of the Terminal

#131

Post by theamk »

9dev wrote: post #122
Borg3 wrote: post #107

Earlier quoted context omitted.

Well, innovating or start bloating? Usually I see things being overengineered because we MUST innovate. No innovation = going backward. Progress bar? what for? Is something like that not enough? Transmiting files: 3/20 (12%), 675kB/s Or sth like that. Far more informative that just progress bar. And can render anywhere, easly, over 9600bps too.

Sure, that is a progress bar. And it's something countless devs have wasted hundreds of man-years reimplementing over and over again, instead of delegating to the terminal application. Because we're stuck with handling transparent character sequences.

This makes no sense to me.

There is only one terminal that user is going to use, and as an app author, you cannot choose which one is it. There is a good chance that your app will run in terminal which was last updated many years ago, and you cannot do anything about it.

On the other hand, you can link to any library you want, and as an app author, you have full (or almost full) control over it. There is a good chance your app will use the libraries you want (especially if its in modern language), and in the worst case you can vendor library locally.

It follows that we should have as much functionality as possible in libraries, and as little as possible in terminals. Your progress bar? Should be a library. If there is a terminal support for it, it should be an optional low-level "eye candy" (some might even call it "bloat"), with all the real logic (like ETA estimation, rate limiting, and formatting) implemented in libraries.

This applies to all your other ideas, too.

"proper inter-process message passing via standardised interfaces" - that exists, and has nothing to do with terminals. Depending on exact details, it is called JSON, DBUS, XML, etc... If you want Powershell-like "ls | select .name", then you don't need to mess with terminal either - it's all shell functionality (maybe with some env var conventions).

Terminals already offer completion like IDEs do, try hitting TAB. I agree it might be nice to use a different font for those, but there is no need for redesign, you only need a new escape sequence like "start/stop floating window" (but again, some might call this "bloat")

Re: State of the Terminal

#132

Post by unshavedyak »

mbrumlow wrote: post #10
unshavedyak wrote: post #8

Earlier quoted context omitted.

Agreed. My only real problem is that font size and "UI" size (gutters/etc) being tied feels like an accessibility tax. Aside from that, they're wonderful. I wonder if we could eventually make a "new term" which shares the same foundation, but atop a rich rendered experience. A GUI written with simple primitives (that could also probably be rendered as TUI, frankly), but with slightly more slick (and expensive lol) re…

It’s called emacs.

I thought Emacs was primarily an editor? Not a general purpose shell, subshells, muxer, etc - not a terminal. I thought emacs would be a singular app?

Eg it sounds like you're saying that Vim is the Terminal if Emacs is the thing i'm describing?

Re: State of the Terminal

#133

Post by thayne »

9dev wrote: post #100
dartos wrote: post #25

Earlier quoted context omitted.

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

> Terminals deal with streams of bytes. But is this a fundamental constraint, or something we can challenge? Is there any good reason why terminals can't deal with structured data instead? > There’s also the ansi standard control sequences, which imo should have more focus on them as opposed to the terminfo db. Everything in that sentence \033[31;1;4munderlines\033[0m the problem to me: If we didn't need to nest meta…

> But is this a fundamental constraint, or something we can challenge? Is there any good reason why terminals can't deal with structured data instead?

What do you mean by structured data? The escape codes are structured. And any structured dat would be sent as a stream of bytes.

Also consider that if everything had to json messages, that would mean that programs that didn't care about controlling a terminal would need to determine if their stdout was a terminal or a pipe, and properly format content if it was a terminal.

I think the concept of escape sequences is fine.

Although, I do wish that there was a way for the terminal and application to communicate out of bound. In particular that would allow querying the terminal without having to worry about getting unexpected input before the response, and you could send graphics or clipboard data out of band without tying up the terminal itself.

> But is this a fundamental constraint, or something we can challenge? Is there any good reason why terminals can't deal with structured data instead?

I mostly agree with that. Although it brings up the question of how an rgb color should be converted to a more limited color set. Should it approximate the nearest color for some definition of nearest, or should it ignore the color setting altogether. Though I think it would be better for that complexity to be centralized in the terminal instead of having to be implemented in every application.

> nor should the terminal itself have to support hundreds of emulation targets

I definitely agree with this.

I think we could use a standard terminal control spec that standardizes the things that modern terminals mostly agree on, and removes things that aren't really used anymore. And have a standard mechanism to query for optional or vendor specific capabilities. And write some decent documentation for the control codes (which if it already exists I haven't been able to find, at least in a single place).

Re: State of the Terminal

#134

Post by mixmastamyk »

pjmlp wrote: post #48
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…

Only in regards to UNIX CLI tools, computing history is full of other kinds of command line interfaces.

VMS used ANSI escapes too, did it not? Windows is moving that direction. Amiga as well? CP/M? Not much left.

Re: State of the Terminal

#135

Post by pjmlp »

hnlmorg wrote: post #126
pjmlp wrote: post #120

Earlier quoted context omitted.

Amiga DOS !== UNIX CLI, and if you don't get why, well so be it, lets worship 1970's printer hardware instead.

I'm giving you the benefit of the doubt that you're just mistaken rather than trolling: 1. I never said Amiga DOS was the same as UNIX CLI. In fact I never even compared the two, that was all you 2. I do get why different command line interfaces are different -- I author a significant amount of code towards terminal emulators, shells, command line tools and maintain a hell of a lot of retro systems. So I'm definitely…

You were the one that was so eager to reply that didn't even bother to go past the first line of my comment, and that says it all.

All the non-UNIX platforms eventually had to come up with POSIX support, because apparently people cannot stop to see UNIX on everything that has a CPU, other platforms be dammed, they better come up with POSIX support, including terminal escape codes.

The only reason to use PUTTY on Windows was and is, UNIX software running under mingw/cygwin.

Same with Windows Terminal, and naturally Microsoft <3 Linux with WSL, again UNIX like software.

Re: State of the Terminal

#136

Post by hnlmorg »

pjmlp wrote: post #135
hnlmorg wrote: post #126

Earlier quoted context omitted.

I'm giving you the benefit of the doubt that you're just mistaken rather than trolling: 1. I never said Amiga DOS was the same as UNIX CLI. In fact I never even compared the two, that was all you 2. I do get why different command line interfaces are different -- I author a significant amount of code towards terminal emulators, shells, command line tools and maintain a hell of a lot of retro systems. So I'm definitely…

You were the one that was so eager to reply that didn't even bother to go past the first line of my comment, and that says it all. All the non-UNIX platforms eventually had to come up with POSIX support, because apparently people cannot stop to see UNIX on everything that has a CPU, other platforms be dammed, they better come up with POSIX support, including terminal escape codes. The only reason to use PUTTY on Wind…

I made reference to stuff past your first line. Maybe you missed it because you didn’t read the entirety of my comment ;)

Anyway, you’re now just repeating exactly the sentiment I made that we were originally arguing against.

Re: State of the Terminal

#137

Post by NackerHughes »

9dev wrote: post #93
revscat wrote: post #89

Earlier quoted context omitted.

> There is more to shells and text interfaces than working within constraints set 50 years ago. Of course. With some minor changes, you could make the same argument many, many technologies we use every day, from IPv4 to SQL to C. Then there is the old saw -- likely apocryphal -- about how railroads are the width they are because they evolved from standards around Roman roads. Even if it is a fairy tale, the moral of…

IPv4 is a great example, because the transition to IPv6, albeit slow, is happening. And that is an all-renewed protocol with a lot of previously impossible, awesome features. There is a way to do this right.

It’s also exponentially more complicated, has addresses that are a mile long and impossible to memorise, and has enabled such marvels as a toaster that outright refuses to make you breakfast unless it’s connected to the internet with an active subscription and all the telemetry that comes with it. Truly a great example of a way to do things right.

Re: State of the Terminal

#138

Post by dontdieych »

canthonytucci wrote: post #54
Workaccount2 wrote: post #42

Earlier quoted context omitted.

I'm bewildered that the "user friendly" flavors of linux still use ancient terminals. If the fact that these distros still lean heavily on terminal use wasn't bad enough, you also need to have a computer intuition from 1985 to feel comfortable using it. At least capitulate to ctrl+v and ctrl+c.

Would Ctrl-c work conditionally based on if there is a foreground process? What if I want to paste in to the process? The command key on macOS really comes in handy here. The “windows” key on most Linux desktop environments I have used is usually pretty under-utilized, perhaps there’s a case to be made that super-v should default to paste.

No post body was provided.

Re: State of the Terminal

#139

Post by Ferret7446 »

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…

Chesterton's Fence is in full effect here. Quite a few people have tried to do exactly what you wish. They haven't really succeeded, obviously.

Re: State of the Terminal

#140

Post by joouha »

wonger_ wrote: post #97
joouha wrote: post #78

Earlier quoted context omitted.

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.

That's an interesting idea. The closest thing I can think of is using an extended box-drawing font: https://hpjansson.org/blag/2024/01/18/chafa-1-14-all-singing... . That doesn't solve the two-colors-per-cell challenge. But it makes for some very realistic terminal images. For higher fidelity rendering, I think the next best option is supporting image protocols like sixels or Kitty inline raster images. I'm not sure…

I've just found that Mintty supports this

https://github.com/mintty/mintty/wiki/CtrlSeqs#overstrike

Post reply on HN