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

51–60 of 159 posts

Re: State of the Terminal

#51

Post by albertzeyer »

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

Re: State of the Terminal

#52

Post by seanw444 »

skulk wrote: post #12
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…

Emacs seems to fit what you're describing pretty closely. It can render as a GUI and TUI even though the GUI can display things the TUI can't (like fonts/images)

It's almost like parent was intentionally hinting for someone to mention Emacs. Probably not, but the degree to which they described Emacs was kinda funny. It may be old, but it's been evolving, and I absolutely love it still. Especially now with LSP. And it's not even hard to get into, when things like Doom exist.

Re: State of the Terminal

#53

Post by vacuity »

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…

While no one is entitled to other's time for free software, your comment is needlessly dismissive and discouraging. People can have legitimate complaints and try to rally others to change the status quo. No one is encroaching on your right to use the software you choose. You also seem to have preconceived notions of what GP envisions. You can stick to your own thing, but don't stifle the creativity and fervor of others.

Re: State of the Terminal

#54

Post by canthonytucci »

Workaccount2 wrote: post #42
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…

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.

Re: State of the Terminal

#55

Post by Longhanks »

pjmlp wrote: post #50
Longhanks wrote: post #43

Earlier quoted context omitted.

True, but no matter the terminal, you still have to deal with either cmd or PowerShell (and its horrendous startup time), "active code pages", and the fact that you cannot write UTF-8 to stdout without it getting messy - you need WriteConsoleW and/or SetConsoleOutputCP but that affects the whole environment, ... cli on Windows was and is painful.

PowerShell 7.4.2 starts in 1s for me.

zsh starts in 0.1s for me. 1000ms is a very noticable latency to me...

Re: State of the Terminal

#56

Post by pjmlp »

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.

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.

Re: State of the Terminal

#58

Post by bitcompost »

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.

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

Re: State of the Terminal

#60

Post by mynameisvlad »

fipar wrote: post #41
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 I don't disagree with your sentiment I have a few comments: "Why are we still dealing with over half a century of cruft?". IMHO that's because we have software running that's over half a century, with organizations depending on it, and so it needs to continue running. This means we need to continue providing that software with the environment it expects. For over a decade, a significant part of my recurring rev…

> Now that is one hill I'm willing to die on: if someone can't figure out how to extract a tar archive just from looking at the synopsis on the man page and scrolling through the options, unless the archive was maliciously named to hide the fact that it's gzipped or something, I think that person would be a pre-junior developer and still have a way to go to become junior.

There’s “let them figure it out” and there’s “this is unnecessarily complicated because of archaic legacy compatibility”. It should not take multiple parameters to untar+gzip a file.

There is absolutely no reason why, if you provide tar a single .tar or .tar.gz with no other parameters, it doesn’t just say “ok this is a tar/gzip file and you probably want to extract it”.

Post reply on HN