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

101–110 of 159 posts

Re: State of the Terminal

#101

Post by yjftsjthsd-h »

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

Earlier quoted context omitted.

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.

Oh, like making arrows by overlaying - with > or ^ with |. I could see that.

Re: State of the Terminal

#102

Post by yjftsjthsd-h »

9dev wrote: post #95
yjftsjthsd-h wrote: post #63

Earlier quoted context omitted.

> I'm bewildered that the "user friendly" flavors of linux still use ancient terminals. Do they? I was given to believe that you can use modern Ubuntu/Fedora/OpenSUSE without needing to open a terminal. > 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. Okay,…

> Okay, let's say we're going to break backwards-compatibility; how should the user kill the running program, and how should they input character literals, and how are we going to implement your change? Please don’t take it personally, but I find it a bit sad that your imagination ends here. These two questions depend entirely on the chosen implementation. If we’re talking about a new implementation, should we really…

> I find it a bit sad that your imagination ends here.

This isn't the limit of what's possible, it's a lower bound of questions that you have to answer if you want to build a replacement.

> These two questions depend entirely on the chosen implementation.

Okay? Feel free to include multiple answers, but you need at least one.

> If we’re talking about a new implementation, should we really start by accepting the limitations and constraints of the existing system as requirements for the improvement?

If you ditch all the behaviors of the old system without figuring out how to shim them in, then you can build a beautiful new system that's free of all the problems of the old system, and that's also free of all users because you just jettisoned all the programs that let people actually do useful work with their computers. We're stuck with 50 years of backwards compatibility not because we love it, but because people need to be able to interact with their machines without relearning everything, and people need to be able to use the machine to run the programs they're using.

Re: State of the Terminal

#103

Post by em-bee »

9dev wrote: post #96
orangecat wrote: post #75

Earlier quoted context omitted.

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

Could you share what you mean by that? I suppose it was sarcasm, but I didn’t get the point.

CSS doesn't fix junior developers [wasting] hours scrolling an obtuse man page until they resort to a half-assed SO response

Re: State of the Terminal

#105

Post by Borg3 »

vacuity wrote: post #53
Borg3 wrote: post #32

Earlier quoted context omitted.

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

But I dont see it as being creative. He is just complaining, not even giving any new ideas.

Re: State of the Terminal

#106

Post by Borg3 »

bmitc wrote: post #65
Borg3 wrote: post #32

Earlier quoted context omitted.

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. > Second, dont like it? Write something better, do show case and maybe people like it and start using it. Anytime I use a graphical tool, command line afficionados effectively reel in disgust. So I'd say that it's those people who need to get over that some people don't like typing in a terminal to do their work and want to work differently and often more ef…

GUI is more efficient? Joke.. JOKE :) GUI have it uses, for example data presentation and visualization. Oh I have nice tools here too. But data manipulation and query? CLI only or mixed where you query in CLI, got graph output.

Re: State of the Terminal

#107

Post by Borg3 »

9dev wrote: post #73
Borg3 wrote: post #32

Earlier quoted context omitted.

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; t…

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.

Re: State of the Terminal

#108

Post by pjmlp »

radonek wrote: post #84
pjmlp wrote: post #57

Earlier quoted context omitted.

Imagine how much work we would do with those additional ms per day.

Once upon a time, I was tasked to rewrite build scripts for windows based team from .bat files to bash scripts (via a git-bash). People on that team were not exactly unix fans, in fact they resisted hard almost everything coming from us linux weirdos. But reduction in build time was so big they asked for this and embraced it with genuine love.

I bet it was a bit more than a few ms per day.

Re: State of the Terminal

#109

Post by pjmlp »

hnlmorg wrote: post #92
pjmlp wrote: post #48

Earlier quoted context omitted.

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

Sure. And aside from Powershell, which itself had to recreate a bunch of common UNIX idioms, which of those other command line interfaces are still in widespread usage? The status quo is ugly but reinventing it is at least an order of magnitude more work than improving upon it.

Amiga DOS doesn't seem to go away no matter what.

IBM and Unisys mainframes and micros.

Smalltalk and Common Lisp REPL environments.

Although probably debatable to consider any of them mainstream.

Re: State of the Terminal

#110

Post by camgunz »

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…

There are libraries and frameworks that abstract this for you: ncurses, bubbletea, etc. At some point, every interface is low-level: GPU geometry is a stream of vertices, a program is a stream of bytes. This isn't some terminal-specific tech problem, it's just kind of how computers are.
Post reply on HN