Hacker News Reader

Comment by atoav | Hacker News Reader

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.

View on HN

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.

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

Those are two instances of text that should not be editable.

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.

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.

You... can? Perhaps I misunderstand you, but doesn't readline solve this problem?

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.

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.

Agree, MacOS terminal has this distinction between Control which is purely terminal modifier, and Command which is purely Mac modifier, hence when I work in terminal on MacOS I do CMD+C - CMD+V and this is consistent with all the other apps, while on Linux you have to either think of CTRL+C as a copy or as a SIGINT, depends on which app you are using.

This was so good experience for me, that I reconfigured my Linux terminal to have Win+C, Win+V and Win+T (for new tab). However this is inconsistent with Linux window management. Since then I have been actively looking for a way to change the Linux OS manager to have default global hotkeys in the MacOS style. Anybody knows how to do that? ( https://news.ycombinator.com/item?id=41439601 - suggested xmodmap is a key mapping way which will break my CTRL+C in terminal )

while writing this I found https://github.com/rbreaves/kinto - I need to give it a try as this (hopefully) is not simple overlay for xmodmap...

Wait, what do you mean not fixable when you can just change the keybind in the terminal app to use ctrl-c to copy?

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.

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

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

> That’s what I mean?

I'm sorry, I thought there might've been some confusion re. actual sigint definition based on some deeper history and ASCII codes (which didn't seem like it from cursory search)

> ctrl-shift-C will send SIGINT

You filter against your terminal app, where Ctrl+Shift+C will continue send Ctrl+Shift+C

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

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.

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.

I see this in situations when terminal relies on readline() to do this stuff, but that isn't installed.

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

I've not had luck with selecting a position with my mouse in a terminal shell, but arrow keys is rarely a problem.

Old enough terminal or old enough host, sure, there can be some fighting involved. Of course, working in those conditions, sometimes backspace doesn't work either and you have to hit ctrl-H like an animal.

But I haven't had issues with that lately.

Press left arrow four time and type “6”.

No option is needed, it’s worked this way since the 90s at least. Mouse is not commonly enabled but would be inefficient to use as hands are already on the keyboard. I haven’t missed it, but it could be set up with a script, no?

If arrow keys not working for you, install a new distro.

You can do this in the default windows Terminal. Which is also how I interface with WSL, so it's also my Linux terminal.

just use fc (fix command)

Reply on news.ycombinator.com