Hacker News Reader

Comment by koiueo | Hacker News Reader

The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.

A bigger UX problem (on Linux) imo is the multitude of clipboards, we have x11, vim... Those can be synchronized or not, they manifest different behaviors...

And btw while apple is often offered as some golden standard for key bindings, I think the situation there is much (MUCH) worse: apps often intercept and handle common combinations on their own, with unclear precedence, which leads to non-deterministic behavior and a complete mess if you want to override any standard combination.

View on HN

> And btw while apple is often offered as some golden standard for key bindings, I think the situation there is much (MUCH) worse: apps often intercept and handle common combinations on their own, with unclear precedence, which leads to non-deterministic behavior and a complete mess if you want to override any standard combination.

Thank you. That is absolutely the case. As someone who had to switch to Mac for work, I found the keybinding situation to be a complete mess. It's also incredibly hard to track down and change certain keybindings, many apps don't have any text configuration to easily modify and require you to go through their GUIs which require you to know what you are looking for (e.g., which app).

> I found the keybinding situation to be a complete mess.

As in: most shortcts work the same across all apps?

> It's also incredibly hard to track down and change certain keybindings, many apps don't have any text configuration to easily modify and require you to go through their GUIs

Any action exposed in menus is handled on OS level in keyboard configuration: https://techtoro.io/blog/how-to-change-keyboard-shortcuts-on...

No, I mean keybindings that are app specific and that are _not_ exposed in the keyboard configuration menu. Case in point, iterm2. Tons of useless keybindings that you have no easy way to see and disable. Let alone the fact that the app immediately crashes every time I try to modify one.

You really assumed I haven't searched - and figured out - how to change keyboard shortcuts?

> keybindings that are app specific and that are _not_ exposed in the keyboard configuration menu

Isn't it the same issue across all operating systems then?

> You really assumed I haven't searched - and figured out - how to change keyboard shortcuts?

You wouldn't believe how many times I've ran into people who said something and it turns out they didn't do something that would fix their issues :)

> Isn't it the same issue across all operating systems then?

Sort-of but not in my experience at least. In Linux there is a tendency of using /etc or .config files, where it's quite trivial to catch/modify anything.

> they didn't do something that would fix their issues

Oh well, I can't say I _fixed_ my issue. My mac usage compared to my linux+i3 usage still feels like bronze age tech, but definitely I salvaged what I could :)

+1; Mac key bindings is a s**show.

BetterTouchTool is my solution. Incredibly hacky and time consuming, but I'm happy with my setup. Now my key bindings are 95% equal across Linux and Mac, so I don't have to spend too much cognitive energy having to remember which system I am using.

I wish we had some sort of key maps that you could copy between machines & OSes, and all the key bindings would work the same way.

> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.

As an university level educator: This is repeatedly a major hurdle for beginners, that makes the terminal (just text) feel like a different thing than just text to them. This and the fact that you can't just select the commands you have written with the mouse or with shift arrow makes beginners go mad, seemingly for no reason. And I count myself in there, I struggled with this for more than a year. When do you paste how? When donyou copy how?

The problem when you're learning this yourself is that you won't even have the correct vocabulary to describe what you want to know, it just feels like 99% of the world works and the 1% that doesn't is the terminal.

I get that this is historical, but if we want people to understand computers betond the consumer level this is literally like Blender changing from righ-click-select to left-click-select. Back then all the pros said it is no biggie just like you, but it turns out it was a biggie, because since then popularity exploded.

We terminal nerds lose nothing if more people understand terminals, quite the opposite.

It's a pain for even experienced users. Popping open the developer tools in the browser because you've done Ctrl-Shift-C is annoying, accidentally calling a group chat of 50 people in MS Teams for the same reason is really annoying.

Ok as much as I like keyboard shortcuts, having a shortcut for making calls is just cruel.

The ctrl-c thing isn't a big deal for me since I copy text to clipboard either using tmux (just selecting is enough) or piping the terminal screen to vim (where I've mapped it to just +)

Oh thank God it's not just me. At least have a confirmation popup for that! Ctrl+Shift+C, Enter isn't exactly onerous for Teams power users.

In ideal world I'd want to have consistent copy/paste. I'm not saying it's perfect now. I'm just arguing that there are bigger UX problems IMO.

BTW, text selection in terminals seems much more annoying to me, than the necessity to press Shift when copying.

That's kind of making the perfect-the-enemy-of-the-good. We can fix the copy/paste situation now, we can't necessarily fix the bigger problems so easily.

But what is the solution? I don't see it.

Doing meta+c/v like in mac?

Thanks, no. Meta is allocated for windows manipulations in all my setups, and I'm pretty confident the approach where modifier keys are tied to specific "layers" of functionality is a more sound approach

I should probably have said "give people the tools to solve". The solution in the OP won't work out of the box for most people, but it would let everyone with a programmable keyboard bind to whatever they like

Re the Mac like approach, I don't think that's actually all that incompatible. Yes, everyone would have to rejig their window manipulation a little, but keyboard shortcuts are a fundamentally different "layer" to ANSI escape sequences...

Totally agree on ANSI escape. But then to me windows manipulations is also an entirely different "layer".

Conceptually copy/paste could fit into that layer. It's like cross-window interface.

But what do we do with ctrl-z and ctrl-a, which are strictly text manipulation?

That's why Alt, IMO, would be a better modifier. And it all organizes into layers like this:

Ctrl - common ctrl sequences (like on Mac today)

Alt - app layer (still works for terminal UIs btw, even today)

Win - os/de/win layer

But wouldn't it make more sense to use the Win key for it than Alt? I think copy/paste could fit into the OS/DE layer.

Maybe. It's borderline text-editing (the majority of usages are text, and probably within the same application).

Also if we consider, how it's implemented: the app is responsible for content-type negotiation, if I copy a file in my file manager, it's the file manager's responsibility to yield file contents of I paste to another file manager, and yield the file:// uri if I paste to a text editor. So also border-line app functionality...

As I said, I don't see an obvious solution, and even if I had full freedom to design everything from scratch, I don't know which option I'd pick.

So we shouldn't go with the obvious solution that will also take the least effort to teach people (pressing the key next to Ctrl instead of Ctrl) because a few people out there have already set those shortcuts to do something magical on their machines?

Ctrl isn't near Cmd on my keyboard. And wasn't traditionally, even on first apple computers it resided where modern caps lock (an absolute waste of space) is.

Your solution is obvious to you, because you don't want to acknowledge the needs of others.

Alt+C/V, if anything, should be a better compromise, IMO. But it's still a compromise, not an obvious solution.

Why is that more obvious than simply adding the shift to all copy operations? Changing to use the windows/options key is a terrible idea.

Copy/paste would be the only operations to use the windows/options key inside of programs, so much for consistency! If we are talking about changing all keyboard shortcuts to use windows/option key instead of CTRL is even worse, you are suggesting we should suddenly change all shortcuts for everyone, because some people can't remember to press the shift in the terminal?

And then there's the fact that pretty much all window managers/desktops use the window/option key for window manipulation (which sort of makes sense). That's not a few people that is almost everyone using keyboard shortcuts of their desktop environment.

If the aim is to have an elegant, OS-wide solution, changing it to the Windows/Meta key makes more sense semantically than keeping it in the realm of program-specific Ctrl shortcuts.

Windows already has WinKey+V which brings up the clipboard manager.

> If we are talking about changing all keyboard shortcuts to use windows/option key instead of CTRL is even worse, you are suggesting we should suddenly change all shortcuts for everyone, because some people can't remember to press the shift in the terminal?

I only said that we should not subtract using Win/Meta key as an option just because some people have fancy setups that already use that. You implied the rest.

> that makes the terminal (just text) feel like a different thing than just text to them

Terminals are a lot more than just text. They were once physical machines. Now they are software emulating those old machines. These machines, physical or virtual, are controlled via in-band signaling. In many ways they are like extremely primitive browsers. Terminals are so old they actually predate copy paste.

> it just feels like 99% of the world works and the 1% that doesn't is the terminal

They don't actually work like all the other applications. They are completely different. Terminals are extremely complex legacy devices that require special kernel support to even work. The terminal line discipline is maintained by the kernel: Linux actually processes every single incoming and outgoing byte.

Nobody really expects to be able to paste text into a video game running inside a Super Nintendo emulator. Terminals are like that. It's actually amazing that modern terminal emulators were able to provide this feature.

> We terminal nerds lose nothing if more people understand terminals, quite the opposite.

Do you want people to actually understand terminals? To me it seems like you want to change terminals into something new that just happens to be easier to understand. They wouldn't really be terminals then, would they?

Things like ^C and ^D and ^[ are literally ASCII characters. Literally. Everything is ASCII text and that includes control characters, whose input is literally enabled by the Ctrl key. These bytes cause the terminal machine and sometimes even the kernel to do interesting things such as sending an interrupt signal to the slave program, closing its file descriptor or interpreting the next bytes as code in a sort of terminal instruction set. Typing on the keyboard just sends these codes into the system which can do any number of things in response.

We simply cannot have "normal" copy/paste with Ctrl-C and Ctrl-V. If we did this, terminals would no longer be the simple ASCII input devices described above.

Getting people to truly understand terminals means they have to understand all this.

It may be a surprise to you, but there was nothing in your post that I didn't knew. I know all that. Just like I know the rationale behind Blender's Right-Click-select.

The terminal as a tool is shaped by its history, but that doesn't mean we have to carry that history with us forever, especially not at all cost. And I say that as someone who values history and has a self-designed physical terminal bell next to my desk. Does your terminal emulator strike a physical bell when you send BEL? If it does not than your terminal has moved on in time for one reason or another.

My point comes from the observation that the terminal is an extremely valuable tool to learn purely from an practical standpoint. Much more of that value comes from what it allows you to do, than from understanding how it works. Just like with Blender, where I as a former feelancer in VFX had no issue at all with right-click select, but occasional users would shake their fist at the heavens and complain about how bad Blender UI was with all its clever concepts. To them the historical understanding of the intricacies of the Blender UI and why "they are holding it wrong" would be utterly meaningless, what counts to them is that they can use the tool. And I agree.

Would I be happy with just any redesign of the terminal? No. But would I be okay if a good redisgn stopped it from working with physical type writers hooked up to main frames or from talking telnet to my oscilloscope? Yeah. I am okay with that. If I really need that there is probably software that still support that and I install that. I know that this is not a simple change, but it is 2025 and we can think about how things should be instead of staying with how they always have been without reason, especially if we are just talking about the defaults.

> It may be a surprise to you, but there was nothing in your post that I didn't knew. I know all that.

Well, it is a surprise to me. You claimed terminals were "just text". You said you taught this to beginners.

It is not surprising to me that those beginners would have difficulties understanding what was going on when terminals started demonstrating that they were indeed more complex than pure text.

> But would I be okay if a good redisgn stopped it from working with physical type writers hooked up to main frames or from talking telnet to my oscilloscope?

If we did that, they wouldn't be terminals anymore. They'd become some new, incompatible system that exists alongside the old school terminals.

I'm not even opposed to it. I love the idea of reimagining and reinventing everything. We just gotta recognize that we're building new systems. The old ones should probably be left alone.

Modern terminal emulators like kitty are working miracles out of this legacy stuff but they are still working within the confines of the system.

> I know that this is not a simple change, but it is 2025 and we can think about how things should be instead of staying with how they always have been without reason, especially if we are just talking about the defaults.

The legacy of terminals is useful even today. Embedded debugging interfaces use them. I wear a modern open source watch which supports a shell through the terminal system. There's just no getting rid of it.

Even swapping Ctrl-C and Shift-Ctrl-C seems like we're just moving the inconsistencies around. Sure, copy paste is now consistent with modern interfaces but now the inputs no longer correspond directly to ASCII. Maybe we could have a vim-like modal interface where in GUI mode all the key combinations would do what we expect from modern systems while in terminal mode they would act like ASCII inputs. This fixes both inconsistencies... At the cost of being an error-prone modal interface.

> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.

I used to think this before I got a job in a Mac-only company. I've since installed Toshy on every Linux machine I own & the difference is night & day. Having to do something extra for terminals to achieve the thing that's so simple & natural (& frequent) in GUIs just feels like terminal emulators are being treated like second class citizens among the installed apps. Having the same shortcuts "Just Work" in exactly the same way through all apps isn't just more convenient, it feels like the OS is elevating terminals to an equal tier of integration.

Which I would've really expected more Linux users would value more than they seem to.

I have the exact opposite problem on a Mac. Things don't just work. You can select text in the terminal and then middle click to paste it. But that only works in the terminal, not anywhere else.

Catches me out a bunch. There is also only a single copy buffer, so to copy from the terminal and paste into a browser I need to replace what was in my clipboard, drives me insane.

> Which I would've really expected more Linux users would value more than they seem to.

Because you get used to it and then don't think about it. I value having two copy buffers over consistency for the sake of consistency.

Command c command v works fine for me because I don’t “optimise” my experience.

It’s a fun game to do I guess but if you become “more productive” by having a slightly quicker mechanism to find a file through 9 different chords on your terminal only interface - you likely aren’t solving problems that are worthwhile.

I've heard this opinion worded slightly different many, many times over the years. I just can't agree with it. You're going to spend thousands of hours infront of a computer, it makes sense to invest time in being "efficient".

You reach a point of diminishing returns with everything. You can only gain so much knowledge/intelligence/experience before every increase in that becomes extremely difficult. Trying to become "smarter" when you are already "smart" is much harder than getting easy efficiency wins.

There are people that take it to the extreme of course, where they spend all their time on extremely tiny efficiency wins instead of learning how to program, but that's the same problem in reverse.

It's a pretty old concept, the first time I've seen it given a proper name was "aggregation of marginal gains" [0].

[0] https://jamesclear.com/marginal-gains

> it makes sense to invest time in being "efficient".

It does. However, spending time remembering which of the different weird buffers something is pasted into is not being efficient.

It's not "weird buffers".

It's a feature you're not accustomed to.

Yes. Yes they are weird buffers in that you have to spend some (minor) effort remembering what exactly is in the "clipboard", "selection", and the difference of invoking them between apps (e.g. having to Ctrl+Shift+V in the terminal).

Oh, and the fact that selection buffer gets overwritten if you switch between apps with active selections.

Oh, usually there's also a cherry on top in that everyone's darling, vim, doesn't even interact with any of those and has its own buffers aka registers.

I'm sure if there was a way to track how many time you make and undo mistakes in copy-pasting the wrong thing from the wrong buffer, your assumptions would be seriously challenged.

> I'm sure if there was a way to track how many time you make and undo mistakes in copy-pasting the wrong thing from the wrong buffer, your assumptions would be seriously challenged.

> Oh, and the fact that selection buffer gets overwritten if you switch between apps with active selections.

What can I tell you...

Use a clipboard manager.

The end.

> Use a clipboard manager.

> The end.

Does it fix the issue with the multiple buffers and minor annoyances?

No. It just adds a different friction point.

The end.

> Does it fix the issue with the multiple buffers and minor annoyances?

The stuff you mentioned so far is all about you not configuring your setup:

- buffers: You configure your clipboard manager to use a single buffer.

- vim: configure to use global clipboard if that's your preference

- X11: dont use legacy software

> No. It just adds a different friction point.

You think using software that implements functionality you deem missing "adds friction", and yet you still want said missing functionality and complain about it is missing.

That's wild.

A clipboard manager solves all of this and doesn't break the consistency and expectation that the same shortcut copies/pastes to/from the same place.

Which one do you recommend? I tried multiple when switching, but none of them quite worked right. I want:

* Two seperate buffers

* Separate shortcuts to paste them

* Selecting text _anywhere_ automatically puts it into the second buffer

I couldn't find anything that did this, so I just gave up and deal with it on my work laptop (and occasionally whine about it on HN when it comes up)

> You can select text in the terminal and then middle click to paste it. But that only works in the terminal, not anywhere else.

I guess this is likely an odd affordance to unix norms rather than a planned/intended shortcut (I've never tried it & never knew it worked anywhere). I'm not much of a mouse user in terminals though so I guess it would just be a little less natural.

Also Emacs keybindings. Being able to use your text editor muscle memory for editing in every text field of every native app is fantastic.

> every native app

That's a very big fineprint. With three most popular apps among developers being (I imagine) browser, jetbrains ides and vs code derivatives, all being non-native, muscle memory becomes pretty unreliable.

But yeah, would be big, if it indeed was universally supported

My muscle memory automatically uses Emacs keybindings for this, in editors like Pluma.. and the whole buffer is gone. Fortunately there's an "undo" option. But I really want Emacs keybindings to work everywhere. I have my various shells set that way.

> Which I would've really expected more Linux users would value more than they seem to.

It's likely that the users who find this annoying will simply stop using Linux.

I find it annoying, it just.. is what it is, you know? Not like other OS choices don't come with their own annoyances, so I have to choose whichever warts I can live with. Right now, that's Linux.

I learned Ctrl-C for "kill program" very nearly before Ctrl-C for copy existed, and long before it existed on any platform I used. I value consistency, but I also value consistency with common practice for the type of application I'm using.

The common failure mode, for me, isn't hitting Ctrl-C for copy in a terminal by mistake, it's hitting Ctrl-Shift-C for copy in a browser and ending up with the console open, or hitting Ctrl-W to delete a word and having it close a tab.

This drives me nuts as well, the number of times I close a tab with C-W, or select all with C-A...

My brain can "switch mode" when on a regular web page, but if I open some kind of "terminal in a page" (i.e. I the AWS console), then I'm 100% it will end up with a C-W.

For me, it happens most often when I have a call open in a browser in one window, and a terminal open on the other half of the screen taking notes, and then switch to the call and start typing something in the chat.

I'd say Ctrl+W is just a terrible shortcut for closing a tab.

It's right near Ctrl+Q, which usually quits an application.

While Q is mnemonic, W is not.

It's too ergonomic and requires very little wrist movement for such a destructive action.

I understand your pain, but I blame the author of this weird convention for the "close tab" action, whoever they are

I think it came from the close window shortcut on Windows back when browsers didn't have tabs.

> This drives me nuts as well, the number of times I close a tab with C-W, or select all with C-A...

I've lost countless SessionManager terminal sessions this way on Windows and Linux.

Kind of wish Firefox allowed one to modify the common keyboard shortcuts in the browser. But considering the open issue on the matter, I won't keep my hopes up: https://bugzilla.mozilla.org/show_bug.cgi?id=57805

The hacks about seems to be basically steal keyboard shortcuts the same way webpages already do; either through an extension[0] or modifying config-pref.js[1]. Neither of which seems very appealing to me. Though, funnily: I did hit Ctrl-W writing this message to delete a word; thank goodness for cache.

[0] https://addons.mozilla.org/en-US/firefox/addon/shortkeys/

[1] https://old.reddit.com/r/firefox/comments/kilmm2/restore_ctr...

What exactly does Toshy do for you? The readme is incomprehensible...

For the specific case of copy-paste in a terminal, you either have to press something extra for paste or something extra for SIGINT - there is no secret third option. You could remap copy (bad for muscle memory) or remap sigint (similarly bad for muscle memory, but also confusing since many terminal apps mention CTRL+C explicitly).

I guess a better place for copy/paste would be WIN+C/V, since it feels like a global function and not an app-specific one, but the way clipboard is implemented makes it an app shortcut by necessity. This convention also doesn't hold with things like ALT+TAB (switch windows) and CTRL+Q (close window), both of which feel like "system" shortcuts but don't use WIN.

So I guess my point is...keybinds are already a mess "because legacy" and any attempt at solving that mess would just result in less universality and worse muscle memory, which goes against their whole reason for existing.

In the grand scheme of things, "when in a terminal, press shift to escape key combos" is a very easy convention to get used to. Also work for mouse integration, for example if you have vim open and mouse integration enabled, but want to select and copy using the system clipboard.

In Windows Terminal CTRL+C is copy if there is a selection and interrupt otherwise. It's very natural.

You can do this with many terminal emulators on linux too. I did it with konsole and tilix, just change the copy and paste shortcut and you get this "natural copy" behavior.

Toshy makes Cmd-C copy in all Linux apps: both GUIs & Terminals. This avoids any clashes with Ctrl in terminal as you're using Cmd for shortcuts everywhere instead.

> there is no secret third option

I assume you're thinking of trying to use Ctrl-C in terminals? The secret third option is never using Ctrl at all outside of terminals.

> I guess a better place for copy/paste would be WIN+C/V

Yeah that would likely be the equivalent of Cmd if you're using a Windows keyboard. That is how it's configured across all apps by default in macOS & Toshy just ports that sensibility over to Linux.

Anyone know if Toshy is usable on xfce? It's not listed on https://github.com/RedBearAK/toshy?tab=readme-ov-file#curren...

You can use XFCE's control panel / keyboard / application shortcuts to assign xvkb invoking XF86Copy and XF86Paste to whatever you like.

xvkb: the X virtual keyboard. In full GUI mode, it saves you when your keyboard is caput. In headless mode, you can synthesize keys not found in nature, or at least not on your physical board.

I haven't tried it but from your link it sounds like it is supported as XFCE uses X11.

The future Wayland support that the XFCE guys are working on uses wlroots so it should be easy for Toshy to support when it lands - there's a few wlroots DEs listed there.

I use SIGINT more frequently in a terminal than copy-paste. I suspect this is also true of most power users. That’s why the situation is the way it is.

I don't think you understand - macOS prioritises SIGINT use by introducing a new keyboard key for copy/paste instead of masking Ctrl. Using SIGINT more frequently is exactly the point.

Since Toshy is emulating Mac behavior, I imagine that copy/paste shortcuts move from the Ctrl key to the Super key.

> Which I would've really expected more Linux users would value more than they seem to.

We use copy on select... what's all of this keyboard shenanigans /s

> A bigger UX problem (on Linux) imo is the multitude of clipboards, we have x11, vim... Those can be synchronized or not, they manifest different behaviors...

I would probably like vim's + register to always sync with the X/Wayland clipboard where possible², but it is perhaps worth pointing out that vim has (at least?¹) 28 "clipboard" slots (+, *, a-z) and this is a feature not a bug. Having accepted that, I would likewise point out that X having a clipboard and selection buffer is an intentional feature. I'd support universally supporting one single shared clipboard that everything uses properly by default, but I wouldn't want to limit the other options to do it.

¹Edit: Nope, much more than that: https://learnvim.irian.to/basics/registers

²Edit: Oh, yes, I do agree that I would be in favor of making that the default register as well so that ex. just `yy`/`p` used it.

> supporting one single shared clipboard that everything uses properly by defaul

Agree. I got to realize how convenient it is to have one shared clipboard by default after I tried (doom)emacs: behaves like vim, has registers like vim, but default register uses the clipboard. I can still use all the registers as much as I like, but the default one is global and can be shared between apps.

I now configure my vim like this.

I still miss this, however, when working occasionally without a graphical session. Perhaps there's a solution, but I haven't yet bothered to look for it.

It should be included in the :OS section, the tty defaults. From the docs.

"This module configures Emacs for use in the terminal, by providing:

System clipboard integration (through an external clipboard program or OSC-52 escape codes in supported terminals). Cursor-shape changing across evil states (requires a terminal that supports it). Mouse support in the terminal."

> I do agree that I would be in favor of making that the default register as well so that ex. just `yy`/`p` used it.

  set clipboard=unnamedplus

I deliberately do not use this beause I don’t want random Vim edits to clobber my system clipboard.

Agreed. I am completely okay with the separate clipboards. Allows stuff like cc or dd followed by pasting in from the system clipboard (different text) without having to go re-copy something because you just overwrote it. I used spacemacs for a while and I absolutely hated the clipboard syncing.

Well, vim has an absurdly large number of registers. You could just do ex.

  "add"+p

(that is, "delete this line into register a, then paste from +")

> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.

It's literraly breaking your muscle memory for one of the most commonly used shortcuts for no reason. It's a pretty big ergonomic blunder

It should be physical keys and they should be the same on every platform. I have at least 20 keys on my desktop keyboard that I never use, it’s not like the real estate isn’t there. Many older non-technical people struggle with combination keys.

If we had physical keys, we could also fairly easily add multiple clipboards like Copy+2 or Copy+F2 could be clipboard #2 without impacting the basic ease of use.

> physical keys and they should be the same on every platform.

That's an easy no, precisely because

> have at least 20 keys on my desktop keyboard that I never use

Very common operations should be ergonomic, i.e. have a convenient location. Unless you mean to make all keyboards split ergonomic with a thumb cluster, so you'd have prime space for copy and paste, adding bad 21st and 22nd key far away will be worse than a more convenient modifier

Also, you forgot laptops where there is not enough real estate to even fit the full standard desktop keyboard

(multiple clipboards would be a great benefit, though)

Status quo bias? First we have a large caps lock key and two alt keys. And we even have a ”Windows key” (probably soon an annoying AI key?). Many languages have additional keys, even on laptops (eg Swedish keyboards have å, ä and ö in addition to English ascii) so the real estate argument feels surmountable. Muscle memory and having to retrain is the real issue - you only want big changes like that at most once per decade or two.

> adding bad 21st and 22nd key far away will be worse than a more convenient modifier

Even if in the scroll lock/pause-break region it would help a lot for those who struggle with modifier keys. With this option you could keep Ctrl+C/V.

> Swedish keyboards have å, ä and ö in addition to English ascii

That counts against you because now you have even fewer keys to work with to add copy/paste, shouldn't that extra physical key be instead used for those extra useful letters?

> First we have a large caps lock key and two alt keys.

My "Status quo" is using them for other better things. And right alt is also currently use for those non-ascii Europeans, so that's not an easy win. Caps lock might be, the current default is a disgraceful waste. So that only leaves Paste

> Even if in the scroll lock/pause-break region

Again, you don't have it on laptops, that's the main source of space constraints, so now you don't have universal muscle memory experience.

> With this option you could keep Ctrl+C/V

Hm, yeah, I thought of a universal replacement.

Fair enough, good points. I still think it’s doable. But we’ll probably not see it for a long time if ever..

Here’s a (probably bad) idea that require no layout changes:

Repurpose the caps key into a ”clipboard key”: if you press it while you have something selected, it copies, otherwise it pastes. The key lights up (caps often have led) it means you have something in the clipboard. An expiry of X seconds is good for privacy anyway (copying a password and forgetting it’s in the clipboard). Cut is two keys: clipboard, delete. Paste-to-replace: delete, clipboard.

I’ll see myself out.

Had the same idea about repurposing a single key for both copy/paste, but then if it's done for the inexperienced users, this modality/overloading is also not great.

I myself sometimes press Ctrl+C twice because there is no other indication (and even with a led, I wouldn't see it since I'd look at the screen), and this misfires my other double Ctrl+C functionality, which at least isn't "destructive" like paste. For the passwords I think it's better to have dedicated clearing API (which I think already exists, if not used everywhere) rather than having a triggering expiring time on anything, that to mee is needlessly hostile, I don't want to ever worry about my copy of a paragraph expiring.

> while you have something selected, it copies

so no replace then?

Maybe use the right middle modifier for the paste? (it's an apps/menu key, is that used frequently enough? though again, some laptops only have 2 modifier on the right...)

> I myself sometimes press Ctrl+C twice

Yes but this would continue working since the clipboard button doesn’t change the selection. You’d just do multiple copy ops. It only changes to paste when nothing is selected.

> so no replace then?

Not in one keypress. You’d first press delete and then (since now nothing is selected), you press clipboard button to paste.

It’s the same number of button presses as Ctrl+V but without modifier keys.

> Maybe use the right middle modifier for the paste?

The modifiers are the main problem imo, because it’s both undiscoverable and evidently difficult for novice users.

> It only changes to paste when nothing is selected.

Ah, right, then this only breaks full-line copying where you don't need to select the line

> It’s the same number of button presses as Ctrl+V but without modifier keys.

true, but delete is in a bad position in standard layouts...

And yeah, modifiers aren't friendly

Another capslocky idea I had: tap to copy, hold to paste? (though also not very noob-friendly)

> That counts against you because now you have even fewer keys to work with to add copy/paste, shouldn't that extra physical key be instead used for those extra useful letters?

Those are not extra physical keys. Some buttons on the left of ENTER has the Å Ä Ö, that's all.

I'm currently on a Swedish TKL keyboard.

See https://typingdonewell.com/blog/what-is-a-nordic-layout-the-...

> Those are not extra physical keys

I know, that's why if you do add extra physical keys, they have to compete with the useful dacritics or the commas that those diacritics replaced, so it's harder to justify using those extra physical keys for copy/paste

Lower on my priority list then separating out linguistic space from list space.

In the shell I want the super key or tab or something to mean "new list item" - no more escaping spaces (this will of course never happen in my lifetime - but if you're rebuilding technology post apocalypse with a clean slate...)

Isn't this what TFA suggests?

All day in ChromeOS at work it's accidentally open the dev tools in chrome (you Ctrl-Shift-C'd when you should have just Ctrl-C'd) or kill my server in the terminal (opposite direction). All. Day.

Same in Firefox. Absolutely infuriating and trivial for them to fix/disable with an about:config even if you absolutely had to keep Ctrl-Shift-C for the masses. I suppose it only affects, oh, everyone in the world who uses both dev tools and a terminal. Which is almost a complete intersection with people who use dev tools! Or have they always been expecting AI to take over web design entirely and you no longer need terminals or something?

You can inject JS into every single page to fix it via an extension, but extensions don't have the ability to fix it otherwise. I suppose you could also intercept it in an IME?

An important lesson to learn is the way X11 does copy/paste (hint: it doesn't).

You select (typically via the mouse) something on the screen. The client (the software that handles this, e.g.terminal emulator, browser, office editing suite) declares ownership on a "selection". There are at least 3 of them: PRIMARY, SECONDARY, and CLIPBOARD.

Nothing gets copied!

When you go to some other client (or even the same) and do a "paste", a request is sent to the first client (the selection owner), "please give me the content". The second client gets the content and does whatever it wants with it, typically inserting it somewhere.

Contrast this way of operation to what other systems (like Windows and Mac) do: the content is copied to a central place, and then copied out to be "pasted". If one wants this behavior in X11, one needs to run something like a "clipboard manager" which can trivially implement this. I must admit, when using Windows, instead of Ctrl-V for pasting, I have completely switched to Windows-V, which gives you at least a history of the copied content.

Going further, on X11, the additional wonderful part is that there are also content-negotiation primitives built-in in this exchange!

So it could be the case that you select some formatted text in your browser, you want to paste it in your text editor (e.g. gvim), the editor asks ("give me the content, in Markdown (or HTML) format") and this is what gets transferred and eventually inserted. Or, if you select an image, you can paste the SVG text that generated it.

I have no idea what Wayland does, but this is another functionality that is extremely helpful and will be missed if not available, when/if X11 is replaced.

> Contrast this way of operation to what other systems (like Windows and Mac) do: the content is copied to a central place, and then copied out to be "pasted".

This is a gross oversimplification to how Windows manages the clipboard. In the general case, the situation is not much different from X11 and the data stays in the sending application until requested - and is lost on program exit.

Really? That doesn't match my experience.

I've just tried: Open Notepad; write something, select and copy it. Exit Notepad. Open browser. Paste. What was written in Notepad gets pasted.

Yes, really. Windows supports 'delayed rendering' (https://learn.microsoft.com/en-us/windows/win32/dataxchg/cli...), whereby an application can choose to not provide the data until requested. Thus, applications have a choice of either providing the data directly if it's a smaller amount, or delaying that if the amount is large enough that a performance impact can be expected.

Moreover, Windows will request that applications that are closing provide their previously advertized clipboard data, making the feature pretty much transparent to users. And some applications ask if you will still need your previous clipboard data when they close (Excel is one, I seem to remember).

A ordinary user would use the clipboard manager installed on their desktop and no part of your description would fit:

* Copied text goes to the clipboard manager as it is selected

* Clipboard manager populates the clipboard buffers as you configured it. For example send copied text to multiple buffers to simulate non-linux behavior.

* User can query clipboard manager for the history whenever

* User can paste anything from clipboard manager. Yes, even if the original app has closed.

I don't even like the solution. "Buy a new programmable keyboard." The keyboard I've got generally works fine. It's not programmable as far as I know, but who knows for sure.

The clipboard has always been annoying. Even today, you often see a "copy to clipboard" or something on a web page, and it never works on Linux. Not as I've got it configured, in any case.

> Even today, you often see a "copy to clipboard" or something on a web page, and it never works on Linux. Not as I've got it configured, in any case.

That's weird. It's a pretty widely available Javascript API for years already. Nothing OS specific on the website's side. Are you running an ancient/fringe browser?

https://caniuse.com/mdn-api_clipboard_writetext

Sure, but the API is primitive and limited. The browser puts it in CLIPBOARD, but then the user pastes from PRIMARY and gets something they didn’t expect. And the author of the web page probably included some event handler(s) that breaks the selection, so that selecting text doesn’t copy to PRIMARY like it should either.

I suppose something like that is going on. Perhaps if I use some kind of "clipboard app" I'll be able to recover it.

Edit: Hmm, got one already called clipman, and it can display the two types of selections, now just have to figure out how to use it.

With X11 you don't even need a programmable keyboard for this, just make your own xkb layout. These support multiple layers just fine.

> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.

> A bigger UX problem (on Linux) imo is the multitude of clipboards, we have x11, vim... Those can be synchronized or not, they manifest different behaviors...

It occurs to me that if there were a universal copy/paste key, then it could be implemented by the OS rather than the applications, such that it uses a single clipboard (or chooses the appropriate one by application type, or even by user choice!) and sends an event (maybe as a signal?) to programs rather than having them scan. Which in turn would make it possible to remove the ability to scan, and thus the ability to have situations like that recent one with StarDict.

I have an interesting work around for that in my sidechat tool (https://github.com/day50-dev/sidechat/blob/main/sidechat/sid...)

It's an inversion. Instead of the user selecting and then having to figure things out, they declare an "intention to paste" and then do the selection.

In practical terms, they invoke the "use clipboard" feature then the code probes all the clipboards (tmux/primary/emacs/nvim/clipboard/secondary) and the user selects their text. One (or more) changes. That's the clipboard it's going to use.

I love the multitude of clipboards.

I love the fact I can select from the terminal, or from the GUI, and I can use Shift + Insert or middle click.

I love how I can have another clipboard using Ctrl-C / Ctrl-V.

I use both on an everyday basis and has been for almost two decades.

I like having bot selection and clipboard, but problem is consistency. In terminal (rxvt) shift-ins pastes selection, while in GTK app, the same shortcut pastes clipboard.

I have not had this issue. Are you sure that everything is configured properly?

> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.

I don't think anything has caused me more pain with computing than this.

And I'm including dealing with Python dependencies.

I almost exclusively use middle click paste when dealing with the terminal (and most other things as I find it much more convenient).

That actually has become more annoying recently, because it seems to work very inconsistently in browsers now. Somehow some websites (e.g. The code blocks in webui, GitHub...) seem to not use the regular clipboard selection so pasting from that doesn't work (I hadnt had time to really investigate)

> A bigger UX problem (on Linux) imo is the multitude of clipboards, we have x11, vim... Those can be synchronized or not, they manifest different behaviors

It's funny though because I'm so used to it I actually have it as part of my workflow and use the different clipboards differently. If I have to use a non-Linux machine for a while I suddenly feel crippled by only having the one.

I also think on Linux it's just a matter of pressing shift in terminals, but I also ended up opening an unwanted developer tools window in Firefox countless times while copying strings between the browser and the terminal due to ending up using the shift inside Firefox as well. Not a dealbreaker, but annoying.

Ctrl ins/shit ins. (Not the home row, but no accidents with it)

came here to post this, but it shares a different clipboard than ctrl+c/v or something??

anyone know the differences?

> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.

You have to know what to add. Sometimes it is shift, sometimes (rxvt) it is alt.

With all kindness: Compared to mac/ios, android and linux and windows ux is death by thousand papercuts. (I’m not saying apple is perfect either, and maybe we have landed in a digital experience world that is broken for nearly everyone anyway, but I digress. :)

I am already cognitively burdened. I do not need developers telling me at what point the cumulative inconsistencies become a biggie. Copy-paste is a common action and each inconsistency I need to learn is away from my core tasks and ability to focus on those is already scarce as f.

Devs do not get to decide how central a terminal is to my workflow, and whether that terminal app deserves to have the right to tell me that it’s now a special butterfly I need to accommodate my cognition for.

But I guess Linux desktop has chosen its path of being only for tinkerers who are prepared to adopt an entire culture of quirks instead of users focusing on what’s important for them in their own lives.

I’m disappointed this still does not fix the core issue of this being broken for everyone by default.

I use KDE as a daily driver at work, privately run windows 12 and maintain six modern macs at my workshop. Of the bunch KDE is easily the best, with the least amount of weird unexpected behavior and the most logical, user-centric way to lay out and present system setting. Windows 11 feels like an archeogical research trip into the UI paradigms of the past every time you need to change the settings, and macOS constantly does things you didn't ask it for and disallows/breaks things you did for the past years. And there are small things like: After every software update I have to manually put shortcuts into the dock again on six computers. They make it harder and harder to run software that hasn't been approved by apple. And the small UI papercuts are easily worse than on KDE (I count here stuff that clearly didn't work as intended, not stuff I have opinions about).

Correction: Windows 11, that was a typo, sorry.

> Devs do not get to decide how central a terminal is to my workflow, and whether that terminal app deserves to have the right to tell me that it’s now a special butterfly I need to accommodate my cognition for.

You must be new to computers. /s

Today's devs do not give a shit about user's needs. They just want change or profit.

I have home key on my external keyboard. While home in combination with any modifiers behaves consistently under Linux, it's an utter mess under macOS. Sometimes my cursor jumps to the beginning of the visual line, other times to the nearest \n before the cursor, sometimes when no text editing is involved, it scrolls the frame, other times it does nothing.

First time I tried macOS I was impressed with the globally (so I thought) respected emacs bindings (^E, ^A, and especially ^N and ^P). But then I have painfully discovered that almost every(?) app just mimics the default scheme, but essentially implements its own handling, which leads to numerous inconsistencies spreading way beyond copy/paste. That's when I realized why most macOS users I've observed use touchpad to manipulate cursor during text editing – there's no reliable universally consistent way of doing this under macOS

macOS is not just "not ideal". It's as messy as other OSes, but with its own bag of unique warts.

But I understand it's easy to ignore them once you get used to them.

> Compared to mac/ios, android and linux and windows ux is death by thousand papercuts

"What you're used to" is a major component of usability. I've had to do short stints on a macOS machine before, and find it a painful experience that I'm happy to be rid of when I'm done. People who are used to a macOS machine sometimes say the same thing about a Linux machine. They can both be right at the same time.

It isn't the only component of usability, to be clear, and it's also possible for applications to be objectively better. But familiarity and usability are often conflated.

> Devs do not get to decide

In my experience Apple devs are the _most_ opionated in terms of telling users how they should use their machine. The UI controls are super touchpad-centric, and it's crazy that a community-driven project like i3 is light years ahead to macOS "wm" features (not to talk about the native UI management). Also they decide for you where the icons to close the windows are, you want to change them? Nope, sorry, you are doing it wrong and can't move them. Your keyboard? Also wrong, you should buy an apple one, otherwise your modifiers are all messed up. You don't use the application docking bar? Well, you are doing it wrong, you can reduce it, but can't remove it, it's always going to be there at the bottom.

There are countless of instances in which the only way to do something is the Apple way, so much so that everyone who switched from Linux to Mac I have spoken with essentially concluded that either you bend to how Apple decided things should be done, or you will be constantly fighting your own machine.

I appreciate that this means that if you start with Apple and get used to their way, you have no cognitive burden on how to do something, but when you use your machine every day, you want to decide how things work to reduce your cognitive load (I.e., this is more intuitive for me this way), and Apple really doesn't like that.

I think he meant devs of 3rd party software, not devs of the OS.

From the perspective of a user, what's the difference?

Yes. Devs tend to want to scratch their own itch, instead of the itch of 90% of the population.

I’m a developer (fullstack, conceptual modeling, db, architecture, c++/qt, php, python, cs degree) who is trained in UX too and using windows and linux is painful because I never get to enjoy the customization part due the poor nature of default UX ie results of bikeshedding everywhere.

It is just too much work to get to basic ok defaults, to have any energy left to think about what I might want to customize.

The system forcing users to customize is just as much use of power as not being able to.

Of course the ideal is progressive disclosure i.e easy things easy (good defaults) and hard things possible (a configuration dialog).

(I’ve written a brief intro to progressive disclosure here: https://savolai.net/ux/ui-design-balancing-user-needs-with-p... )

But the line has to be drawn somewhere, as apple has. Being able to bikeshed and customize anything can easily become a multiplier of complexity and maintenance cost. It’s not any less opinionated than wanting to keep things reasonably simple.

For some it’s a reasonable tradeoff, for others not. For me the value of apple consistency and aesthetics far outweigh the costs. Sure, there is a learning curve and change resistance I had to go through coming from win/linux, but I wouldn’t say macos has any significant barriers to what I can do. Quite the contrary with M class cpus.

Iphones are another story, but eventually the tradeoffs outweigh android ux illogical nature and inconsistency there too.

I respect the personal opinion, but I personally find unbearable the number of times Apple devs demonstrate to think to know better how I should use my machines. Having sane defaults and customizing basic things (like not using a docking bar, or moving icons on the window on the other side) is something that I don't think requires any maintenance, or at least nothing that a trillion dollar company can't afford.

> For me the value of apple consistency and aesthetics far outweigh the costs.

For me this has ~0 value. I use a device multiple hours every day, muscle memory that makes sense for me is 100x more important that an abstract consistency for things that do not make sense for me. I know that different people have different priorities, though. To make a similar example, I use routinely two keyboards, a TKL and a split 58-keys keyboard. I use 2 layouts (one en-US and my native language). I have absolutely no trouble switching from one to another, and from one layout to another, it requires no effort or concentration, it's all muscle memory and context awareness. The same is with devices or programs for me. Consistency is for what _I_ decide is important to stay consistent, otherwise it doesn't have an absolute abstract value.

> It is just too much work to get to basic ok defaults, to have any energy left to think about what I might want to customize.

I have used Linux for about 10 years before I became even aware of all the things I could do with it. For everything I had to do from high-school to university I never touched more than the basics (Ubuntu and Mint, at the time). I think the defaults were totally OK, and nothing _needed_ to be customized. When I started working I started having additional requirements and the flexibility allowed me to customize and make more efficient the aspects of my workflow I considered important. All of this to say, while this is my experience, I can't relate at all with what you are saying.

> Iphones are another story, but eventually the tradeoffs outweigh android ux illogical nature and inconsistency there too.

I can't comment much on this. I find iOS UX to be completely a mess, full of hidden interactions (on this topic, see https://interactions.acm.org/archive/view/july-august-2025/s...), but I use my only iPhone minimally just for my work phone, so I concede this is a matter of habit (as it's probably the opposite - given 90 yo tech illiterate people can use Android phones).

Thanks for your respectful response.

To me it seems that developer/tinkerer types strongly live in an echo chamber. Of course we are both speculating here, but to me it seems that's exacly where apple derives its market value. By emphasizing the needs of designer types and "ordinary people" in contrast to techies.

The former don't necessarily derive lots of value from, say, having real file systems, which tinkerers often want.

I would claim ordinary people buy android mainly due to price. (Ofc there are also premium android phones where change resistance and pure marketing on both sides of the fence may affect decisions more)

I would propose that those strongly committed to learning tech, rarely see the amount of work they have put into learning and tweaking the system. They do not perceive it as work but as a) having learnt "general knowledge" and b) something they want to do as a matter of fact.

Product/framework thinkers is another way to think of this: https://savolai.net/ux/product-and-framework-thinkers-when-d...

Those people often, unsurprisingly, are also developers.

So those who want to focus on multitude of other things in life and don't want to invest so much in dev tech, don't have their voices heard in dev communities. I have always felt very marginalized here. (Please don't read this wrong, tinkerers absolutely also enjoy a "multitude of things". The emphasis is just perhaps more specialized in a specifically weighted way.)

The "hidden controls" link you provide is interesting, as it could easily be used as an argument against the original linux terminal copy paste issues too. Terminal use in and of itself is of course an example of everything being hidden by default.

It seems in touch interfaces no one can completely avoid this, or at least the industry has strongly moved away from complete visibility/affordances. Which is kinda fascinating, in such visual medium. I would love a physical keyboard but can see why that didn't pan out.

Windows UX has many warts too, but the idea of a single system clipboard where I can copy paste between a console and a web browser in either direction using the same shortcuts in both, seems like a really low bar for an acceptable clipboard UX.

With all possible kindness...

> Devs do not get to decide

I'm sorry but developers get to decide literally everything. They're the ones putting in the work. They build the systems they want for themselves. They solve the problems they personally care about in ways they personally feel is best.

If you want them to build the system you want, you'll have to pay them.

> But I guess Linux desktop has chosen its path of being only for tinkerers who are prepared to adopt an entire culture of quirks instead of users focusing on what’s important for them in their own lives.

This betrays your attitude. You think what we do is not important. You don't care about the system, it's just "cognitive burden" to you. Only your "core tasks" matter.

"Users focusing on what’s important for them in their own lives" -- that's us. We just happen to care about and focus on the system itself. We enjoy the freedom to rebuild the system according to our vision of how things should work.

Numerous independent tinkerers developing their own systems naturally leads to inconsistency. It's a very organic process. It's a mess, but that's okay. Our freedom is far more important than conforming to some "standard" in order to "reduce cognitive load".

If solutions converge, let them do so for the right reasons, namely that it leads to a better system for us. Other people don't really matter.

My biggest annoyance by far is that select on multiple browsers location bar does let you middle click paste the selection. You have to copy and paste.

I'm not sure I've seen the sci-fi movie where Apple is heralded as the golden standard of key bindings, but having used Macs for a few years in real life, I can attest the key combinations are an absolute atrocity for the reasons you mentioned and then some.

While I grew to accept some advantages of my Mac can't be easily replicated in other platforms, I think it is severely lacking in basic features, user experience and it's still occasionally infuriating even in 2025.

I do have a very long list of Mac gripes, as is probably deductable from this comment.

Reply on news.ycombinator.com