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