Hacker News Reader

Comment by francislavoie | Hacker News Reader

Not having smart copy is a complete dealbreaker to me https://github.com/alacritty/alacritty/issues/1919

Windows Terminal has smart copy by default now and the UX improvements of it are a huge difference. I use pantheon-terminal (i.e. the one from elementaryOS) on my linux environments, and the only reason is because it also has smart copy.

It means that on all the applications I use, Ctrl+C does _exactly_ what I expect, all the time. I don't want to have to context-switch when I go to a terminal and remember "oh yeah, I need to hold shift too" and accidentally kill the running process like a "tail -f" that I have running for logs on some server.

I understand it might be technically difficult to implement, but it means I can't switch to Alacritty without inevitable daily frustration.

View on HN

As someone who spends most of his computing time under macOS, this by far is my most frequently encountered frustration under Linux. You get so used to ⌘-C and ⌘-V doing the same thing everywhere, terminal included, and when that's gone it's maddening.

Copy on select, who needs a keyboard ;)

Copy on select is the bane of my existence. I use selection as a reading aid, to follow where I'm looking and to help me focus. I do this in the terminal all the time. If it clobbers my clipboard, this does _not_ help me.

Then don't use it? Selection doesn't overwrite the clipboard, unless your system is configured to do that specifically.

To elaborate, X11 has two clipboards by default:

PRIMARY: Copy by select, paste with middle click or shift-insert.

CLIPBOARD: Copy with explicit copy action, paste with explicit paste action (mostly ctrl-c/ctrl-v, except in terminals/vim)

I'm not sure if this is carried over into Wayland. I've seen some Mac terminals offer copy on select and there it does clobber the clipboard, unlike on Linux.

Vim exposes these as the * (PRIMARY) and " (CLIPBOARD) buffers

Wayland keeps the same behaviour

Thanks for letting me know about smart copy, I had to check which GTK terminals support it:

- Tilix supports it, just set Ctrl-C/Ctrl-V as copy/paste and it'll intelligently handle it.

- Kitty does as well, but needs to be configured manually to do so.

- Terminator has a smart copy option enabled by default.

- No support with default GNOME terminal.

EDIT: I stand corrected, GNOME terminal supports it as Tilix does: just set Ctrl-C/Ctrl-V as copy/paste. Perhaps this works with all VTE-based terminals?

I mean, with Xorg, just select and middle click. Am I missing something?

Yes. It's not like every other app that exists on my system. Context switching is a nightmare. Stop shipping bad UX.

Select+middleclick works with every app on your system.

No it doesn't, in a browser, middle-click will turn on drag to scroll, unless you click on a link in which case it will open a new tab. Which is something I use every day.

Grandparent said:

> with Xorg

The behaviour you describe only happens under windows.

Okay you're right - but on Firefox on Linux which I just tried, middle click doesn't copy. It actually just does nothing.

I mean... it pastes, not copies. Selecting copies, middle clicking pastes.

Someone has probably written a javascript widget that breaks it, but if it's a textarea or the URL bar, you can middle click to paste.

Selecting most definitely does not copy. It would be horrendous if it did.

Selecting in X absolutely does copy to the PRIMARY clipboard. Selecting then copying (e.g. with Ctrl-C) copies to the CLIPBOARD clipboard. Middle clicking pastes from the PRIMARY clipboard, and Ctrl-V pastes from the CLIPBOARD clipboard. It is incredibly useful, not horrendous.

Edit: and you yourself confusedly claimed selecting copies just an hour ago: https://news.ycombinator.com/item?id=24017588

I was talking about copy-on-select in terminals, i.e. terminals I no longer use cause I find that behaviour very frustrating.

Well there's nothing special about terminals, it should work the same everywhere you can select text. It goes into a different clipboard from where explicit copying goes (though most modern distributions have a way to turn on synchronising of the two clipboards - maybe you have that on without realising?).

It 100% does. Every app, select copies to primary.

Middle click to paste only pastes when you're clicking in a place you can type input, like a text box or the URL bar. Just places Ctrl-V will paste. Middle clicking links to open new tabs works perfectly, as do other uses of middle click, like closing browser tabs.

If the focus is not in a text field it doesn't make sense to paste.

But if the focus is in a text field (where it actually makes sense to paste) in a web browser, then middle clicking does in fact paste, just like it does in every other sane X application.

I understood the comment as middle-click would copy, not paste, because I was talking about copy behaviour primarily. Yes middle-click to paste does make sense in input fields.

It’s cognitive overhead to remember a different key for something as common as copy+paste. What if selection was holding down middle click and copying was right click? This keybind may seem easy for you but it is arbitrary and therefore hard to remember, and is non-standard. I struggle with different copy semantics across OSes and terminals all the time. It’s very frustrating.

That's your cut buffer.

Heavy/Traditional Xorg users have enjoyed + gotten used to the multiple clipboards available. [1]

Users are migrating to Linux from Windows/MacOS and are not used to it; and asking for changes. (Remember Chrome + FF changing the selection behavior on the address bar to match windows?) [2] [3]

[1] https://wiki.archlinux.org/index.php/Clipboard

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=26140

[3] https://news.ycombinator.com/item?id=22832199

I don't know what a cut buffer is is, but middle click copies to primary

clipboard is the Windows style paste. I personally never really use clipboard, as using primarily is so much easier. I guess there might be using it at the same time, but I've personally never felt the need for two buffers at the same time.

I'm primarily an urxvt user: select copies & middle pastes. What terminal are you using that middle click is mapped to copy?

Sorry, i meant paste on middle click.

> I've personally never felt the need for two buffers at the same time

I find two buffers convenient when grabbing both url and title for a hyperlink.

I use both, but I admit it's a bit idiosyncratic.

When immediately pasting after copying, the primary X buffer is obviously superior as it requires fewer actions, and only one hand.

However, if I'm selecting something to keep in the buffer for a bit before pasting, I'd often screw myself by overwriting the buffer via random clicks in between.

Now I'm in the habit of using primary in the cases when I know I already have an input field or prompt ready and waiting, and the very next thing I'm going to do is paste. When there are steps left to be performed after copy but before paste, I use the clipboard.

I know it sounds overcomplicated and perhaps insane, but it's actually totally automatic at this point, and doesn't feel like it costs any mental cycles at all. For the first case, either I just readied the other program for input within the last few seconds, or at least it's visibly waiting for input on my screen. If not, then Ctrl+C it is.

For Ctrl+C, I can see how the program can be made to differentiate between which one you want by whether something is highlighted.

But how does it know what action to take on Ctrl+V?

I've literally never used Ctrl+V for anything other than paste, so I'm honestly not sure how it's implemented on Windows Terminal or pantheon-terminal. But the way they have it, it always does what I expect.

I'm also very much not a vi user because, for similar reasons, context switching is a nightmare. I use nano everywhere because it works almost exactly like everything else in my system (but honestly I should probably install micro everywhere).

Ctrl+V is for quoting a control character.

IOW: if you press Ctrl+D, it will cause EOF on the input stream. If you press Tab, it causes your shell to attempt to autocomplete. But if you press Ctrl+V Ctrl+D, or Ctrl+V Tab, it will insert ASCII code 0x04 or 0x09, respectively, into the input stream.

I use SHIFT-INSERT in Windows Terminal (and in Linux terminals too, actually, where it works great).

That requires using both hands and not only my left hand; if I'm scrolling around or clicking around, I'll have my right hand on my mouse. Ctrl+C/V is a one-handed hotkey and works in every other application. I'm not going to use a different hotkey for a single application. Like I've already said, context switching is a nightmare. I want the same basic hotkeys everywhere.

You could make Ctrl+V send SHIFT-INSERT if you wanted.

Okay sure, but that still doesn't solve anything because the fundamental issue is with the Ctrl+C in Alacritty not behaving the way I'd want it to.

Hmm.. I wonder if you could get your desired behavior by rebinding Ctrl+C in Alacritty to copy, and also using the "stty" command to change the keyboard shortcut that sends the interrupt signal from Ctrl+C to something else.

The latter may be necessary because traditionally you would interrupt programs (like say a runaway cat command or some other long-running process) with Ctrl+C, so using Ctrl+C to copy would normally conflict with that.

Though I suppose that a terminal could be implemented in such a way that Ctrl+C is used for copy if some text has been selected and when no text has been selected it could pass that Ctrl+C on to the application running in the terminal. This way Ctrl+C could remain as the shortcut for sending an interrupt signal to apps in the terminal, and you wouldn't have to mess with stty.

Remapped to control shift v which can be used with one hand

I set alacritty to bind

chars: "\x03"

which is what Ctrl+C normally sends, to Ctrl+Shift+C, and copy to Ctrl+C. This is after getting used to the default behavior of VTE-based terminals (like GNOME Terminal), which set Ctrl+Shift+C to send Ctrl+C if you set copy to Ctrl+C.

(Also "\x04" (Ctrl+D) to Ctrl+W, which will close things like python if it's running or the terminal if nothing is.)

You can try mapping it to super+c/super+v, as macos does. (If apps you use don't support key rebinding, then a little xdotool|autohotkey|autokey magic can do it.)

I don't use a mac though, and no, very no, thanks. I want my terminal to have the SAME hotkey as every other app on my system, not something different. And I'm not going to relearn Ctrl+C/V with a different hotkey globally. That's too crazy an ask.

Every decent app should support copy paste with ctrl+insert/shift+insert and doesn't conflict with terminal use of control characters... The alternative is to stop using terminal emulators.

You can also set interrupt to something else than ctrl-c, using stty.

Reply on news.ycombinator.com