Solvedalacritty Linux: copy paste with ctrl-c/v

Which operating system does the issue occur on?
Elementary OS 5 (Ubuntu based distro)

If on linux, are you using X11 or Wayland?
X11

Alacritty: compiled latest from master.

I understand that Alacritty uses ctrl-shift-c/v but is that just preference or is there some technical limitations for this?

I am asking because the default terminal app on Elementary OS (as one example) allows copy with ctrl-c when text is selected and acts as SIGINT when nothing is selected.

I am not sure how other terminal apps do it.

26 Answers

✔️Accepted Answer

The two main arguments against this seem to be

  1. It would be confusing if set as default
  2. It could be confusing if text is selected without the user realising

The counter argument would be

  1. It is confusing if a user manually sets the copy keybind to Ctrl+C but they can no-longer send SIGTERM, having used other terminals where this works as they expect.

I'd propose that

  1. This shouldn't be default. For better or worse on linux, Ctrl+Shift+C is the standard for copying in a terminal.
  2. Copying should (optionally?) remove a selection. This way if you type Ctrl+C twice you are guaranteed to send a SIGTERM. If this is optional, perhaps note that this is recommended wherever the dual action Ctrl+C ends up being documented.
  3. Either document that this is or isn't possible.

Personally, I really like this behaviour having discovered it while using Windows. I like how I don't have to remember to use a different keybind exclusively in terminal emulators. Right now this is the only thing keeping me from using alacritty.

I don't think this has to be particularly intrusive or obnoxious to those who don't want it, but it would be really handy and would work well for those who do.

Other Answers:

Windows terminals also work like that, in particular WSL. It's not a UX nightmare, on the contrary. It's perfect.

You should expand your worldview and get the good stuff from non-linux terminals and the GUI world in general. Unlearning that copy is "ctrl-shift-c" in the terminal and "ctrl-c" everywhere else, and instead having "ctrl-c" being copy everywhere, that was a huge win in my experience. I've used linux terminals for years and the amount of times I killed the running process instead of copying text has not been negligible, because of accidental "ctrl-c" instead of "ctrl-shift-c". And there's the constant mental overhead of having to be aware of which is the right copy shortcut at any given time. On the contrary, being on WSL for a couple of years, it feels liberating. Accidentally killing something just doesn't happen. And if I want to kill the process I'm looking at and "ctrl-c" isn't killing, all I have to do is click on the command line right in front of me (thus unselecting) and "ctrl-c" again. (this is also exactly what you do in another common error when working in windowed GUIs, which is that you think you've selected the terminal window, but some other window is actually selected, so you're trying to do something in the terminal, you see it unresponsive, so you click it thus making it the active window and try again. this process becomes second nature)

Now Alacritty does support a scrollback buffer though. So there's no reason why a selection would have to be visible for Ctrl+C not to work. If you ask me that's a UX nightmare. An invisible selection thousands of lines away in the scrollback buffer could be the sole reason why copy/pasting isn't working anymore.

I'm not sure you thought this through. If there's an invisible selection thousands of lines away, everything keeps working just fine. "Ctrl-v", you paste it. select something else and "ctrl-c", you copy something else. "ctrl-c" intended as a SIGINT, and not working? click right in front of you, "ctrl-c" again, it's working.

I think this is a really bad idea and there are a couple of reasons that play together why I think it is.

My first issue is mostly about element of least surprise. Would Alacritty configure Ctrl+C as the default for copy/pasting inside the terminal, then a lot of people used to terminal emulators could get really, really confused. This could of course be fixed by not setting it as a default, but then there's a need to document it so people actually know about it.

Now Alacritty does support a scrollback buffer though. So there's no reason why a selection would have to be visible for Ctrl+C not to work. If you ask me that's a UX nightmare. An invisible selection thousands of lines away in the scrollback buffer could be the sole reason why copy/pasting isn't working anymore. And if you set it up so it only works when the selection is visible, then users will get confused again.

So this isn't straight-forward and I do not think there are any good ways to handle it. Building it into Alacritty will always require some special workaround which might affect users unrelated to this feature and it could contribute to a lot of 'weird' heuristics thrown around the codebase. But thinking about the benefits, there doesn't seem to be enough to support this change. People are used to ctrl+shift+c, it works, if you want to press less keys, you can bind the copy and paste keys (which are bound by default). I feel like this wouldn't solve an issue that doesn't exist.

If there's any better idea to handle this cleanly without running into any of the issues I've mentioned, please let me know. But as far as I'm concerned there doesn't seem to be a good way to implement this and it seems like a shallow UX improvement that would actually make things worse if you actually look more into it.

It's really unfortunate that you have such a strong stance against an opt-in feature. Especially since there are those who consider this a dealbreaker with Alacritty.

The implementation could just be something simple, similar to what I have in my fork. And I think you'd gain a lot of love from users.
Anyone who doesn't want the smart copy behavior can simply go about their day. This wouldn't affect them.

But I guess the only viable solution for us is to find ourselves another terminal that will do the job.

For those who end up here through google like me: The link above lists a few alternative terminals with this feature. Personally, I'd recommend Kitty, using the copy_and_clear_or_interrupt function.

Thanks for your time.

So found this issue because I have started to move to linux from windows and I've been trying different terminal emulators but I hadn't really found any yet that support ctrl+c for copy and terminating commands like Windows has the option to (am trying the elementary terminal now, didn't know it had that). Found this issue searching for if alacritty could, since apart from this, I liked it.

In windows it works similar to the elementary terminal except when something is running it pauses when you select and you can change the selection, then when you hit ctrl+c it clears the selection and continues running. Even without that pausing behavior, I like that first ctrl+c copies, and any subsequent ones terminate.

Actually I just tried the Window's version of alacritty out of curiosity, and it seems to handle things more how I want, but still different then either windows or linux. ctrl+c copies if nothing is running (no new lines on subsequent presses though), otherwise it terminates the running command. That's kind of what I would like in linux, except, subsequent presses should add a new line.

It doesn't have to be the default, but an option to have it work like in windows would be nice, or some way to make the commands context sensitive? Like:

 - { key: C, mods: Control, action: Copy when: !was_last_press && not_running}
 - { key: C, mods: Control, action: Terminate when: was_last_press || running } 

Also, I can't really find how to set the shortcut to terminate to something else (it autosets it to ctrl+shift+c?). Maybe I missed it but I didn't see it in the list of actions.

More Issues: