241–250 of 262 posts
Earlier quoted context omitted.
It rendered perfectly, without JavaScript, in Emacs EWW.
I used to try EWW sometimes, but it sometimes made whole Emacs crash at unpredictable times, so I stopped trying to use it. But good to know, maybe I will try again in the future, hoping it becomes more stable/safe.
Claude Code et.al. are good examples of that. Diffs, user approval flows, non-linear flows in general and a ton of text buffered are all elements that we know really well how to handle in web interfaces but are challenging for the terminal.
Earlier quoted context omitted.
possible isn't the same as supported and working. A non-terminal hunt-and-peck typer sits down and is presented with a terminal, what's the second that happens when they're typing? they make a mistake and try to click on the word they misspelled, and it doesn't work.
That’s a very specific gripe to make. So specific that you have to acknowledge it’s not going to be a deal breaker for everyone. Which makes me wonder why you’d use the “Stockholm Syndrome” argument — assuming you used it in good faith and not just because you wanted to sound edgy (or some approximate synonym of)
Earlier quoted context omitted.
possible isn't the same as supported and working. A non-terminal hunt-and-peck typer sits down and is presented with a terminal, what's the second that happens when they're typing? they make a mistake and try to click on the word they misspelled, and it doesn't work.
What TUIs are you referring to? Mouse is supported and working on just about every TUI framework.
I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely. I get why people build TUIs, but it’s…
Here's why I use them: many modern graphical applications are extremely wasteful. TUIs are typically small, low footprint applications that don't come bundled with a browser or webview. I don't need yet another electron app for every little thing.
That ship has sailed. These days, TUIs are often Node.js / React monstrosities. Claude Code is a case in point.
I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely. I get why people build TUIs, but it’s…
What is great about them is the constraints they impose on the UI designer. I spend so much time finding actions in apps like Zed, Obsidian or Slack because menus and rows of buttons are not cool anymore. I'd really want explicit UIs from 2000, but in the mean time TUIs feel like an improvement.
Earlier quoted context omitted.
They are GUIs --- just minecraft GUIs. One day, we will rediscover why GUI toolkits exist. The only real advantage TUIs have over GUIs is easy remoting, TBH. Maybe that's enough for people. Otherwise? They're just hair shirts.
I've use Claude to make myself a number of little tools and weird apps that only I would want lately. They need to be cross-platform between Linux and Mac and sometimes Windows. The best approaches I've found are Tauri (+Svelte for making layout easier) for lightweight GUIs but for anything more complex I prefer a TUI. The Ratatui framework works very well. A TUI feels like a "real" app as opposed to a glorified webp…
Earlier quoted context omitted.
> to Commodore 64 level That’s unfair to C64 which can smooth scroll very well.
I owned a C64. Remember how buttery smooth the interfaces of those '80s computers were?
Earlier quoted context omitted.
That’s a very specific gripe to make. So specific that you have to acknowledge it’s not going to be a deal breaker for everyone. Which makes me wonder why you’d use the “Stockholm Syndrome” argument — assuming you used it in good faith and not just because you wanted to sound edgy (or some approximate synonym of)
It's a thing that confuses every single person the first time they touch a terminal! Could do without the diction-based ad hominem.
I get that. But it doesn’t mean those that prefer the terminal have Stockholm Syndrome.
The terminal is a UI optimised for keyboard entry. So of course mouse input to move the caret wouldn’t be something that is prioritised to support.
Again, that’s not Stockholm Syndrome; it’s just a different workflow.
> Could do without the diction-based ad hominem.
You’re the one making ad hominem attacks by saying CLI users suffer from “Stockholm Syndrome”. That was your comment not mine.
I said I was willing to take your comment in good faith. Which isn’t a personal attack.
I’m really not interesting in meta arguments nor using intentionally antagonistic language. And if you continue to communicate this way then I will just ignore you.
Earlier quoted context omitted.
What TUIs are you referring to? Mouse is supported and working on just about every TUI framework.
bash readline
So old that Charm, the framework featured in this article, is written in a programming language that was decades away from conception back when readline was first released.
Comparing modern TUIs to readline is like comparing an analogue rotary phone to a smartphone.
Readline is also no longer the default experience for your average new user since macOS switched to Zsh many years ago and Microsoft will push Powershell over WSL in the row documentation.
I do get the point you’re trying to make. But it’s a pretty weak argument give the age of your examples.