3 ms·

If I could change two things about terminals it was thesd: 1. Make text editable with a cursor and mouse selection like in any other modern text application

by atoav 2y ago

If I could change two things about terminals it was thesd: 1. Make text editable with a cursor and mouse selection like in any other modern text application 2. Make use of the normal and expected text shortcuts for copy, cut, paste, select all etc. Make ESC *escape* the current program. And I am a heavy terminal user who has no issues with how it currently is, but I also have to teach these things... I am aware that such a change would probably be 1000 times more complex to pull off than most people would think, but every time I have to explain to beginners they can't edit the text I die a little inside.

skydhash 2y ago
The use of a terminal is to communicate with an application (the shell mostly, and other REPL software). The text shown is a log of that interaction, not the interaction itself. We could probably design a better interaction model (smalltalk, plan9) but the current one is the most simple.
- atoav 2y ago
  I understand that. But there is no reason (other than legacy cruft) why I shouldn't be able to fix a typo mid-command with arrow keys instead of backspace before sending that command as a default. I am perfectly fine with having sent commands uneditable and responses uneditable as well.
  - scbrg 2y ago
    You... can? Perhaps I misunderstand you, but doesn't readline solve this problem?
fragmede 2y ago
The frustrating thing is that the code for mouse move/selection already exists, but it's a total rathole to get it working, and I don't have the whatever to be a whatever maintainer across everywhere.
ninkendo 2y ago
macOS’s terminal app does #1 but you have to option-click. It’s kind of a hack too, it just issues a bunch of right/left arrow key codes to the shell to move your cursor to the designated spot. Your second point is definitely my #1 issue, at least it is on Linux and Windows (macOS at least uses Cmd-c everywhere and it works.) I have to constantly remember to use ctrl-shift-c to copy in the terminal but ctrl-c to copy everywhere else, and I constantly forget and use ctrl-shift-c in a not-terminal program, and do something stupid like open dev tools in chrome, ugh. This is, unfortunately, not fixable. Not without rewriting every app on my system to use a different copy/paste combo.
- eviks 2y ago
  Wait, what do you mean not fixable when you can just change the keybind in the terminal app to use ctrl-c to copy?
  - ninkendo 2y ago
    Ctrl-C is SIGINT, I don’t want to change its definition of sigint just to make room for copy behavior. What I want is to make a different shortcut trigger copy/paste, everywhere, and that’s not fixable. Every app independently decides to make ctrl-c implement copy, so changing that is basically not possible.
    - eviks 2y ago
      You don't need to change the definition of sigint, just its shortcut! Though it's also possible to fix it everywhere - use a keyboard rebinding tool to make Ctrl-Shift-C send Ctrl-C key combo instead
      - ninkendo 2y ago
        > You don't need to change the definition of sigint, just its shortcut! That’s what I mean? Changing sigint’s shortcut isn’t what I want to do. > Ctrl-Shift-C send Ctrl-C key combo instead Then ctrl-shift-C will send SIGINT too, and I’m back to where I started (SIGINT and copy having the same shortcut)
mixmastamyk 2y ago
You can edit text, at the prompt. Afterwards output is readonly and copyable. Doesn’t make much sense another way.
- atoav 2y ago
  Yeah? Like in a normal text editor? Please write: echo "12345789" and insert the missing number without deleting the already existing numbers in a vanilla (non-emacs, non-vim) terminal. In nearly every other editable text field people know well in their lived (including the one you typed in for this comment) you can move your cursor to the middle of a sentence and insert text with a mouse click or the left/right arrow key. And before someone suggest some option to enable this: my comment was about changing the defaults.
  - drcursor 2y ago
    just use fc (fix command)
  - skydhash 2y ago
    The terminal model is just to display the text that the currently running software provides and send input to it. It’s not a text editor. The prompt is a feature of the shell and other REPL programs, not the terminal. Bash and Zsh and others use readline which allows text editing like navigation [0]. And there’s rlwrap for programs that lack these. [0]: https://readline.kablamo.org/emacs.html https://readline.kablamo.org/emacs.html
  - wpm 2y ago
    Press left arrow four time and type “6”.
  - joh6nn 2y ago
    Using the arrow keys to navigate the current input is well supported on most modern terminals, and has been for most of my adult life. If this isn't working properly in your terminal, then I'd recommend experimenting with the various settings available to you. Some terminals also support mouse navigation, so keep an eye out for that as well. I'm sorry that you've been dealing with this frustration for so long and under the impression that it was just supposed to be that way and not fixable. The good news is that it's NOT supposed to be that frustrating and you CAN fix it Edit: you edited your comment somewhere between my first seeing it and my reply posting. I haven't had to modify the default settings on my terminal to fix things like this in about 20 years. I've changed them to tweak various preferences like scrollback, cursor shape/size, etc. But arrow navigation has worked out of the box for me for so long that I literally can't remember when I last had to fix it. I don't know why our experiences have been so different, but I'm sorry that a tool that has been so useful for me has been so frustrating for you.
Ferret7446 2y ago
You can already do this, in Emacs and possibly other terminals. It is pretty easy to implement. The problem is that this can also cause other problems, especially for newbies, because editing the text may not do what you think it will do (e.g., editing the output of ls or editing a command after you started running it).
- atoav 2y ago
  Those are two instances of text that should not be editable.
crabbone 2y ago
1. I probably don't care. On the list of things I want from a shell (what you are asking for isn't a function of the terminal, but of the program running in it) this is so low, I would never cared if it was added. I never wanted it to work like this, but as long as it doesn't actively get in the way, I'm OK with it. 2. What's "normal"? Do you mean CUA-style navigation? In that case, absolutely, no effing way! These keybindings are awful. And it's good that they are awful. It wouldn't be a good idea to often accidentally press C-c and kill whatever thing you are working with. But, it's not a convenient key chord for an operation as common as "copy". Now, you may say "in addition to already existing text editing key bindings": but then, again, no, because I want these keys for rare and dangerous operations. I don't want them to be duplicates of existing and better functionality. NB. Both of your improvements aren't about terminals. They are about programs run by terminals (eg. shells). But you probably knew that already. I realize that OP and the comments lump all these tools together under the same label. But it's still worth pointing out that these are separate issues at least in the sense that nothing you can do to the terminal will effect the change you want to see.

by atoav 2y ago

skydhash 2y ago

The use of a terminal is to communicate with an application (the shell mostly, and other REPL software). The text shown is a log of that interaction, not the interaction itself. We could probably design a better interaction model (smalltalk, plan9) but the current one is the most simple.

atoav 2y ago
I understand that. But there is no reason (other than legacy cruft) why I shouldn't be able to fix a typo mid-command with arrow keys instead of backspace before sending that command as a default. I am perfectly fine with having sent commands uneditable and responses uneditable as well.
- scbrg 2y ago
  You... can? Perhaps I misunderstand you, but doesn't readline solve this problem?

fragmede 2y ago

The frustrating thing is that the code for mouse move/selection already exists, but it's a total rathole to get it working, and I don't have the whatever to be a whatever maintainer across everywhere.

ninkendo 2y ago

macOS’s terminal app does #1 but you have to option-click. It’s kind of a hack too, it just issues a bunch of right/left arrow key codes to the shell to move your cursor to the designated spot. Your second point is definitely my #1 issue, at least it is on Linux and Windows (macOS at least uses Cmd-c everywhere and it works.) I have to constantly remember to use ctrl-shift-c to copy in the terminal but ctrl-c to copy everywhere else, and I constantly forget and use ctrl-shift-c in a not-terminal program, and do something stupid like open dev tools in chrome, ugh. This is, unfortunately, not fixable. Not without rewriting every app on my system to use a different copy/paste combo.

eviks 2y ago
Wait, what do you mean not fixable when you can just change the keybind in the terminal app to use ctrl-c to copy?
- ninkendo 2y ago
  Ctrl-C is SIGINT, I don’t want to change its definition of sigint just to make room for copy behavior. What I want is to make a different shortcut trigger copy/paste, everywhere, and that’s not fixable. Every app independently decides to make ctrl-c implement copy, so changing that is basically not possible.
  - eviks 2y ago
    You don't need to change the definition of sigint, just its shortcut! Though it's also possible to fix it everywhere - use a keyboard rebinding tool to make Ctrl-Shift-C send Ctrl-C key combo instead
    - ninkendo 2y ago
      > You don't need to change the definition of sigint, just its shortcut! That’s what I mean? Changing sigint’s shortcut isn’t what I want to do. > Ctrl-Shift-C send Ctrl-C key combo instead Then ctrl-shift-C will send SIGINT too, and I’m back to where I started (SIGINT and copy having the same shortcut)

mixmastamyk 2y ago

You can edit text, at the prompt. Afterwards output is readonly and copyable. Doesn’t make much sense another way.

atoav 2y ago
Yeah? Like in a normal text editor? Please write: echo "12345789" and insert the missing number without deleting the already existing numbers in a vanilla (non-emacs, non-vim) terminal. In nearly every other editable text field people know well in their lived (including the one you typed in for this comment) you can move your cursor to the middle of a sentence and insert text with a mouse click or the left/right arrow key. And before someone suggest some option to enable this: my comment was about changing the defaults.
- drcursor 2y ago
  just use fc (fix command)
- skydhash 2y ago
  The terminal model is just to display the text that the currently running software provides and send input to it. It’s not a text editor. The prompt is a feature of the shell and other REPL programs, not the terminal. Bash and Zsh and others use readline which allows text editing like navigation [0]. And there’s rlwrap for programs that lack these. [0]: https://readline.kablamo.org/emacs.html https://readline.kablamo.org/emacs.html
- wpm 2y ago
  Press left arrow four time and type “6”.
- joh6nn 2y ago
  Using the arrow keys to navigate the current input is well supported on most modern terminals, and has been for most of my adult life. If this isn't working properly in your terminal, then I'd recommend experimenting with the various settings available to you. Some terminals also support mouse navigation, so keep an eye out for that as well. I'm sorry that you've been dealing with this frustration for so long and under the impression that it was just supposed to be that way and not fixable. The good news is that it's NOT supposed to be that frustrating and you CAN fix it Edit: you edited your comment somewhere between my first seeing it and my reply posting. I haven't had to modify the default settings on my terminal to fix things like this in about 20 years. I've changed them to tweak various preferences like scrollback, cursor shape/size, etc. But arrow navigation has worked out of the box for me for so long that I literally can't remember when I last had to fix it. I don't know why our experiences have been so different, but I'm sorry that a tool that has been so useful for me has been so frustrating for you.

Ferret7446 2y ago

You can already do this, in Emacs and possibly other terminals. It is pretty easy to implement. The problem is that this can also cause other problems, especially for newbies, because editing the text may not do what you think it will do (e.g., editing the output of ls or editing a command after you started running it).

atoav 2y ago
Those are two instances of text that should not be editable.

crabbone 2y ago

1. I probably don't care. On the list of things I want from a shell (what you are asking for isn't a function of the terminal, but of the program running in it) this is so low, I would never cared if it was added. I never wanted it to work like this, but as long as it doesn't actively get in the way, I'm OK with it. 2. What's "normal"? Do you mean CUA-style navigation? In that case, absolutely, no effing way! These keybindings are awful. And it's good that they are awful. It wouldn't be a good idea to often accidentally press C-c and kill whatever thing you are working with. But, it's not a convenient key chord for an operation as common as "copy". Now, you may say "in addition to already existing text editing key bindings": but then, again, no, because I want these keys for rare and dangerous operations. I don't want them to be duplicates of existing and better functionality. NB. Both of your improvements aren't about terminals. They are about programs run by terminals (eg. shells). But you probably knew that already. I realize that OP and the comments lump all these tools together under the same label. But it's still worth pointing out that these are separate issues at least in the sense that nothing you can do to the terminal will effect the change you want to see.