4 ms·

The problem with TUI's, that we have all Stockholm syndrom'd ourselves, is that I can't use the mouse cursor to click to the position on the screen and edit the

The problem with TUI's, that we have all Stockholm syndrom'd ourselves, is that I can't use the mouse cursor to click to the position on the screen and edit the command line.

verdverm 9mo ago
You can use the mouse with TUIs build on the Charm stack https://github.com/lrstanley/bubblezone https://github.com/lrstanley/bubblezone There are a lot of components that resemble things you find in web component libraries
willm 9mo ago
It is possible. Terminals have supported mouse interactions for a long time.
- fragmede 9mo 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.
  - hnlmorg 9mo ago
    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)
    - fragmede 9mo ago
      It's a thing that confuses every single person the first time they touch a terminal! Could do without the diction-based ad hominem.
      - hnlmorg 9mo ago
        > 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.
        fragmede 9mo ago
        You're taking the Stockholm syndrome thing way too seriously. I wasn’t trying to imply terminal users are irrational or trapped, I'm just pointing out that some default behaviors are genuinely non-obvious to newcomers and feel rough around the edges at first. That’s more about historical ergonomics than user psychology. Terminals optimize for keyboard-centric workflows and composability. Once that mental model clicks, a lot of the tradeoffs make sense. But the first-contact confusion is real and pretty universal, which is what I wanted to highlight. I agree it’s not useful to escalate into meta arguments about tone. Different tools, different workflows, different preferences. The interesting part is how we lower the initial friction without losing the power that keeps people using them decades later. Which, Ghostty added cl=line support in e06742b36ec9, so we're getting there!
  - HarHarVeryFunny 9mo ago
    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.
  - willm 9mo ago
    What TUIs are you referring to? Mouse is supported and working on just about every TUI framework.
    - fragmede 9mo ago
      bash readline
      - hnlmorg 9mo ago
        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.
        fragmede 9mo ago
        zsh uses zle, but mouse reporting is off by default.
baq 9mo ago
I’ve built textual tuis (as in the Python library) and it responds to clicks just fine.
MisterTea 9mo ago
FWIW, Plan 9 windows work this way. They are just plain UTF-8 buffers with no typewriter emulation. You can edit any text you wish. If you want graphics, the draw device is a 2D graphics compositor you load assets into then issue rendering commands. Text is a draw primitive and easily displayed any way you want, angled, rotated, moving around, colorful. VT emulation is accomplished by vt(1) which does VT over stdio and emulates an ANSI typewriter using the draw device and it works well. You could even write a Plan 9 native TUI That way, just run it under vt(1). But I would not recommend that - go native.
johan914 9mo ago
Emacs vterm can do this. It's the only terminal emulator I'm aware of that can, because it seems nobody else cares. It can even backspace and delete all the text selected.

The problem with TUI's, that we have all Stockholm syndrom'd ourselves, is that I can't use the mouse cursor to click to the position on the screen and edit the command line.

verdverm 9mo ago

You can use the mouse with TUIs build on the Charm stack https://github.com/lrstanley/bubblezone https://github.com/lrstanley/bubblezone There are a lot of components that resemble things you find in web component libraries

willm 9mo ago

It is possible. Terminals have supported mouse interactions for a long time.

fragmede 9mo 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.
- hnlmorg 9mo ago
  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)
  - fragmede 9mo ago
    It's a thing that confuses every single person the first time they touch a terminal! Could do without the diction-based ad hominem.
    - hnlmorg 9mo ago
      > 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.
      - fragmede 9mo ago
        You're taking the Stockholm syndrome thing way too seriously. I wasn’t trying to imply terminal users are irrational or trapped, I'm just pointing out that some default behaviors are genuinely non-obvious to newcomers and feel rough around the edges at first. That’s more about historical ergonomics than user psychology. Terminals optimize for keyboard-centric workflows and composability. Once that mental model clicks, a lot of the tradeoffs make sense. But the first-contact confusion is real and pretty universal, which is what I wanted to highlight. I agree it’s not useful to escalate into meta arguments about tone. Different tools, different workflows, different preferences. The interesting part is how we lower the initial friction without losing the power that keeps people using them decades later. Which, Ghostty added cl=line support in e06742b36ec9, so we're getting there!
- HarHarVeryFunny 9mo ago
  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.
- willm 9mo ago
  What TUIs are you referring to? Mouse is supported and working on just about every TUI framework.
  - fragmede 9mo ago
    bash readline
    - hnlmorg 9mo ago
      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.
      - fragmede 9mo ago
        zsh uses zle, but mouse reporting is off by default.

baq 9mo ago

I’ve built textual tuis (as in the Python library) and it responds to clicks just fine.

MisterTea 9mo ago

FWIW, Plan 9 windows work this way. They are just plain UTF-8 buffers with no typewriter emulation. You can edit any text you wish. If you want graphics, the draw device is a 2D graphics compositor you load assets into then issue rendering commands. Text is a draw primitive and easily displayed any way you want, angled, rotated, moving around, colorful. VT emulation is accomplished by vt(1) which does VT over stdio and emulates an ANSI typewriter using the draw device and it works well. You could even write a Plan 9 native TUI That way, just run it under vt(1). But I would not recommend that - go native.

johan914 9mo ago

Emacs vterm can do this. It's the only terminal emulator I'm aware of that can, because it seems nobody else cares. It can even backspace and delete all the text selected.