91–100 of 159 posts
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…
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.
The status quo is ugly but reinventing it is at least an order of magnitude more work than improving upon it.
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 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…
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.
> 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,…
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 start by accepting the limitations and constraints of the existing system as requirements for the improvement?
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...
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.
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 how overprinting would compare to existing options.
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…
> But I wish there was an effort of building a new, modern, textual interface to computers with modern assumptions and integration bindings. Would it be different from a web-browser? Isn't the webstack already the modern textual interface everyone is using? I mean that's also the direction they all are walking to, with adding images to terminals, having more complex layout with TUIs. I think I remember some TUI-toolk…
I would argue that the web stack is really more of a virtual machine, or OS-agnostic application runtime, but it is not a textual interface per se (albeit it certainly can be used that way).
On the other hand, I'm looking for solid primitives to make applications talk to each other, but with structured data instead of plain text open to liberal interpretation; for terminals that don't emulate a teletype device, but make use of modern operating systems. Think of what we had before systemd—the wild west of shell scripts, layers upon layers of arcane compatibility hacks—and what we have now—a standardised, documented, structured, system management interface that works the same way everywhere (please don't lets discuss systemd here, it's just an analogy).
So rather than trying to paint NodeJS-lipstick on the TTY-pig, I'd like to see a new kind of terminal protocol that solves the UX issues of old.
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…
Why can't we make it backward compatible so an interface has each client application say "I support the new interface" if it does? You probably would need to add kernel support to handle the fork/execve case, but I don't think that there is an intrinsic limitation.
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 sequ…
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 metadata into the byte stream, none of us needed wrestle with escape sequences. And that such a thing like the terminfo db even needs to exist speaks volumes about the lengths we have to go to to accommodate for decades of cruft…
Applications should neither be concerned with what color codes the output device can render, nor should the terminal itself have to support hundreds of emulation targets.