Comment by fragmede
5 days ago
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)
It's a thing that confuses every single person the first time they touch a terminal! Could do without the diction-based ad hominem.
> It's a thing that confuses every single person the first time they touch a terminal!
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.
A terminal emulator in a GUI environment such as Linux is expected to play nice with the GUI and support mouse-based select, copy and paste, as well as being a terminal emulator, and this means that the terminal itself is consuming mouse events to support text selection.
If you wanted to write a shell that has mouse support you could certainly do so, and this would be based on sending escape codes to the terminal to tell it to return mouse events as input rather than let the terminal consume them itself. The shell could then itself support the clipboard if it wanted to, as well as support mouse editing.
I just googled it, and apparently "fish shell" does exactly this, but your hypothetical user is more likely to stumble upon a bash shell which is letting the terminal emulator consume the mouse events and support copy and paste.
What TUIs are you referring to? Mouse is supported and working on just about every TUI framework.
bash readline
Readline is one of the oldest libraries available on modern systems.
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.