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.
> 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).
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.
> 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
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?
> 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 :)
> 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 +)
> 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.
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.
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
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?
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.
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.
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...
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.
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
> 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 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.
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.
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 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.
> 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.
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].
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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
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.
> 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.
> 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."
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.
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.
> 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 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
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.
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...)
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.
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...)
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.
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?
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.
> 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.
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 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 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.
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.
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.
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.
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).
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).
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.
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.
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).
> 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.
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.
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.
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.
> 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'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.
I think Apple did the right thing by keeping GUI shortcuts separate from terminal control codes.
I never understood why the Linux GUI world ran blindly after Windows and emulated every pattern, good or bad. And yes, I know that Ctrl-C/Ctrl-P for Copy/Paste are much older and came out of IBM's CUA and SAA initiatives. What matters is that with the Mac we had a clear role model how to handle this aspect of GUI cleanly but me missed it.
While we’re at it, I’m still on the lookout for IBM’s original SAA and CUA documentation. If anyone has these lying around, I’d be interested
> I think Apple did the right thing by keeping GUI shortcuts separate from terminal control codes
They are separate because they ditched terminal shortcuts and later begrudgingly brought them back. The original Mac didn’t have a control key. They added it back in 1987 because of pressure of terminal emulator programs.
You mean they successfully resisted the temptation to repurpose Ctrl, even though they were sure never to need it again. They did the right thing by introducing a new key for a new thing.
The problem is not the lack of alternatives but the embrace, extend and extinguish of established Ctrl-Key combination standards.
I am not angry at Microsoft because that is what they do. I am disappointed of Linux that it followed suit.
Besides that, every Mac has Ctrl and Option, the vast majority of users does not have dedicated Ins and Del anymore and I doubt they know how to use the Fn combos for that.
I use ctrl-Ins/shift-Ins and it works in my terminals and in the browser. I've not checked if it works in other apps because ctrl-c/ctrl-v always work in other apps. I'd be happy if ctrl-Ins/shift-Ins just always worked; I don't need innovation here.
While we're talking keyboards, what about emoji? Every messaging app has a different interface for them, some like Discord and Whatsapp allow you to use :smile: shortcuts, but the enumerated names are different across apps. I've occasionally gotten a dedicated OS emoji picker to show up on my Mac, but I don't know how.
On Ubuntu Cinnamon, I managed to create keyboard shortcuts for the 8 or so emoji I use the most by binding something called a "compose" key and modifying a .XCompose file, but it still took other config file gymnastics to make it persist between X sessions.
`Meta + .` opens an emoji picker on KDE. And you can type unicode with `Control + Shift + u`.
I've been meaning to look into this, but what I'd really love is a composer which can insert any text, emoji, or unicode character based on whatever alias I give it. I'd probably leverage more of unicode if I should hit a shortcut and type wd to summon a wave dash (〜).
Support varies - GTK needs an environment variable to use it and Qt (since version 5) only uses the first code point of the result. No idea about Wayland support or alternatives.
That's just regular keyboard for CJK languages. "today" -> "2025/08/15 Fri", "cry" -> ":crying_face:", etc. It's just small extension to regular "keycodes to full UTF-8 gibberish" process that input method editors handle.
There's nothing wrong if someone make ones for en, fr, de, in my opinion. Correction-plus-conversations like "hors douvray" to "hors-d'œuvre" in one key is going go be useful.
I like how Apple introduced the CMD key, with copy/paste linked to it in the terminal, leaving CTRL to work as intended. Even outside the terminal basic emacs key binding work as intended, such as c-k c-u etc
That's an arrangement I also really appreciate. But the origins are different from what most might assume.
Apple introduced copy and paste in 1983 using the command key. Microsoft later copied the idea using the control key because PCs lacked a command key [1].
X had super, meta, hyper keys before the PC's stunted set of modifiers became a standard [2]. Microsoft and the PC are rarely the origins of things, mainly because CP/M, DOS and later Windows were poor, amateurish, and incomplete copies of other systems.
I use Toshy along with an Apple keyboard to work around Linux distros' unfortunate Windowsiness here but I really really wish someone would release a fully fledged distro or DE put together with Apple keyboards in mind.
There's a lot of things about Apple I dislike but it's clear Microsoft's overloading of Ctrl for GUI shortcuts was a move made with complete disregard for terminal users, & one that's resulted in decades of pain for anyone regularly switching between GUI & terminal contexts, & I have to give it to Apple that Cmd was clearly designed to respect, retain & augment optimal terminal use.
OTOH, Microsoft's introduction of "menu accelerators" (Alt+*) is an incredible productivity booster (which luckily most Linux graphical toolkits have adopted).
I got to appreciate it only after I had to use macOS at work.
Somehow I got used to Ctrl workarounds in terminal emulators (just add shift). But the lack of accelerators bugs me immensely.
I find them a little too dependent on individual app developers word choices to have any kind of consistency across apps I use, plus I tend not to use menus for anything other than infrequent settings changes. Given that they haven't seemed substantially different to macos displaying annotations for bound shortcuts within the menus.
(admittedly I use mac in work & my personal computers at home have all been Linux since my Windows 2003 workstation died, so my knowledge of modern windows apps & their attached accelerators is rusty & I'm probably biased here)
The last windows I used was XP. But accelerators do work in Linux.
And they are not just about menus: in any modal window I can do Alt+O for Ok. And this paradigm allows discoverability, I don't need to memorize shortcuts, I just hold Alt and look for underscored letters – that's how GUI should be IMO.
It's not perfect, and if I were designing UI from scratch, I'd made this feature modal instead of allocating entire physical key for that (like they do hints in vim-like browsers).
> I like how Apple introduced the CMD key, with copy/paste linked to it in
As someone who switches between macOS and Linux every day, the change of control-key from CTRL to CMD is hella annoying. I am always pressing the wrong combo on macOS.
I completely agree. If only Windows also had WinKey+C/X/V as shortcuts, it would make so much sense in other Windows software too. Same with ALT+TAB and ALT+F4, CTRL+SPACE etc, these should also be handled by the win key. Then the Win/Cmd key would be assigned to OS functions, and the rest of them could be assigned to application functions, providing a clean separation.
Ctrl is different. Alt and Win don't cancel themselves when released, they are modal, and modal sucks. Ctrl is the only safe key besides Fn, so repurpose Fn if you must.
It's ancillary to this post, but I don't understand this obsession with "programmable" keyboards, at least for plain remapping of keys. There's entirely no point in doing it; the keymap / layout (not application key bindings, before that) is what gives keys meaning to begin with. Why would you care about what keycode a keyboard sends for some key? The only thing that matters is NKRO, if you want to remap modifiers; on non-NKRO keyboards the modifier keys are different in that they don't clash with other keys.
If the keyboard has some macro function, okay, I can see that being useful, in rare circumstances (in most cases you could also just do that in software.)
Meanwhile, the only way to get a keyboard that has 2 physical keys in the space where the wide caps lock key is on a "normal" keyboard is to build it myself. That key is the one completely useless key in the "core" of a regular layout, and I'd really like to be able to put 2 custom functions there (rather than just 1).
The keymap functionality in your OS is a hack because most keyboards are not programmable. I use a split keyboard in a Colemak layout, and it's programmed to send the correct keys despite them being in "different" places compared to a normal keyboard, so I don't have to mess with keymap switching on the operating system. I just plug it in and it works.
Also what you deem obsession is called ergonomics. Since a programmer uses a keyboard 100% of the time they spend in front of a computer, optimising for ergonomics is a great time investment. My symbol layer is so much more sane and comfortable than having to use Shift-number like an ape (no offence). In the home row under my strongest fingers, for example, I have "():_= which are the most common symbols in popular programming languages. My two thumbs are not wasted to press an humongous space bar, but have access to modifiers such as Shift and Ctrl instead of having to use my pinkies.
The secret to not losing muscle memory when you have to go back programming like an ape on a regular keyboard, is to choose a very different physical layout (like an ortholinear split keyboard) for your programmable keyboard. Then you're just learning another "instrument" which is spatially laid out differently than what you are used to, retaining your memory of QWERTY on a regular keyboard.
That's a matter of perspective. Sure, the keyboard could know the labels printed on it and send the proper key, and you could see it as "change my labels, change my keyboard's understanding of the labels and send the right thing".
Or, you could see it as "the keyboard is an input device with about a hundred possible actors, that have something printed on them to help the user distinguish". An input device's function —even if it is a keyboard— is being an input device, not necessarily inputting letters or keys. If I want to map the key labeled "U" to bring up the second last terminal window, that's valid. Not being able to input "U" now is my problem to solve. And a programmable keyboard, as programmable as it might be, can never cover the undefined set of things users around the world would want to make some keys do. So you'd have to split it in two remapping operations. But why? It's added complexity and confusion.
In your specific case, my position (which, yes, because it's not how things work in USB/BT/…, is somewhat meaningless) is that there should be a function where the keyboard reports both the labels on its keys as well as the physical layout. (And then keypresses relative/in reference to that.)
And the thing that kinda drives my position home is an annoyance a lot of German (QWERTZ) and French (AZERTY) people know: Game inputs quite commonly use WASD layouts, and those get warbled quite a bit. As they would (even worse) on your reprogrammed Colemak layout.
P.S.: your "ergonomics" and "use a very different layout" points seem to have misunderstood my position/argument. I'm saying remapping keys / different layouts should be a general OS/software function, not something the keyboard does in its microcontroller. I'm entirely on board with "fancy" layouts.
> there should be a function where the keyboard reports both the labels on its keys as well as the physical layout
You can move the keycaps around, though you'll find they don't all have the same height. Or wait until someone releases a keyboard with a small e-ink display in each keycap that doesn't cost an arm and a leg.
QWERTY is not a problem. I have a dedicated layer just for games, which is actually a QWERTY/Colemak hybrid. The left side is QWERTY, as most game keys are bound near WASD, while the right side matches closely my Colemak key maps, so whenever I have to write text in QWERTY mode, I just have to mentally map from QWERTY the left-side. In practice, this is not a problem. Non-rebindable games are just small indie ones I find on itch.io that only use WASD. The rest that have in-game text chat I rebind, and Colemak anyway is very close to QWERTY not to make that effort too onerous. 99% of games are just WASD + TEF.
Re: QWERTZ and AZERTY: those are abominations and shouldn't exist. I use QWERTY everywhere + a dedicated Compose key for diacritics.
I can't help but notice nothing you're arguing is in relation to which part of the system should be doing the mapping from abstract keys to actual letters. As such I don't see anything to engage with…
(It's also a bit strange that you argue your freedom of choice to use Colemak and then immediately proceed to call two other layouts "abominations and shouldn't exist". And this is where I'm cutting my participation in this course, because even though I absolutely agree they exist, I'm not interested in discussing objective advantages of keyboard layouts over each other. If you're arguing ergonomics, you need to accept that for a lot of people the thing they're used to is the most ergonomic because the cost of adjustment far outstrips the benefits.)
Ctrl-Ins for copy, Shift-Ins for paste, is something that works everywhere in a graphical desktop, including my (KDE Plasma 6 Konsolepart) terminal. AFAICT the clipboard is the same.
Not enough people know that you can just select text then middle click somewhere to paste it. No keys required and yes it works with all terminal emulators I've tried. This has been default behaviour on Linux desktops for as long as I've used it (decades).
The problem with this (and to me it's a super annoying problem - marking and pasting with left and middle button is super fast and efficient) is that some browsers (or maybe it's the toolkits behind them) start to either ignore this functionality or force you to repeat the action before it works.
I'm almost exclusively using firefox and I encounter it on some websites and not others. In particular selection in code boxes is the thing that often doesn't work. So I suspect it's actually not the browsers but some websites playing weird js shenanigans.
Depends what you mean with "to select something"; for example if you click on the URL bar in Firefox then all the text is automatically selected. Should that count as the user "selecting" something? Perhaps not? None of this is very straight-forward.
If I do that in a Chrome-based browser, the text looks like it's selected, but it isn't. Same if I just mark the text using the left button. It won't paste when I click the middle button. I have to click again, then double click, and then it'll paste - most of the time.
Elsewhere I either double-click on a word, which will select that word for pasting, or I mark a section with the left button (press and hold at the beginning of the selection, move and release). And the middle button will paste. And paste again, if I wish.
But URLs in Chrome-based browsers instead behave in the annoying way described above. In the past it worked as expected.
The fact there is a totally different way to copy text in the terminal is the issue, it just breaks the common mental model. Even worse, this shortcut _requires using a mouse_, and not just for copying, also for selecting!
X has had two clipboards for longer than I've been using it, which is nearly three decades.
If your mental model of clipboard interaction only involves a single clipboard, and you use X, your mental model is simply wrong.
Sure, you could change X to match your mental model, but now you've broken the mental models of everyone who actually learned to use the software. And one more useful feature that makes X nice to use gets sacrificed to please the people who came from Windows but desperately want everything to work like Windows.
MacOS has for me the best basic keybindings even thanks to the keyboard hardware design and the fn button placed on the left side, which is the right one, as it opens the door to have home/end/pgup/pgdown with fn + arrows, and high ie perfect for 65% keyboards, I’ll never understood why pc keyboard and mech ones have the fn on the right side, totally useless.
UN*X has 2 copy/paste buffers and they both work on Slackware with a Window Manager under X11 as you mentioned. I think the same is true with DE.
Is that not the case with Wayland ?
Anyway, I always liked how these worked when compared to Microsoft. Again, I do not what to see this change.
Plus we already have enough keys on our keyboard. I think Microsoft is in the process of adding an AI key, crazy. I do not look forward to 1000 keys on a laptop keyboard, already I fat finger the current keyboards too much.
Where mod is the cmd key. It works well in most apps. At least in those I care about (terminal, browser, vim). Took me a very long time to find this solution, as a macOS refugee.
Not necessarily a MacBook, by the way. I have an Apple Keyboard with my PC (just a great keyboard I enjoy), so it works there too.
Been a linux user since 2016 when I found an Ubuntu 16 installation CD in a drawer wirh old books. The thing for me is having ctrl+v paste without formatting. (If I need to retain formatting, I will gladly do ctrl+shift+v)
Maybe it's just me but, I'd gladly scroll endlessly looking at pictures of old keyboards / HID devices. (I use a Fellows KU-9938 Split Keyboard and a Kensignton)
We gonna get support for keys that don't exist on any modern keyboards, don't worry though you can remap them or bind them to change mplicated macro layers in your expensive mechanical keyboards.
Do all that and you won't need those two lines of xinit.rc
Even when the Ins and Del are there, they're at the far right top of the keyboard, which requires moving the hand to reach them every time.
It used to be less of a hassle when those shortcuts first appeared (with IBM CUA), as Ins/Del were just slightly above the arrow keys that you'd use to select the text prior to copying/cutting it anyways.
Yes, but GP didn't imply that they would hit ctlr-Ins/shift-Ins with the right hand. GP complained that the right hand has to move a fair bit to reach Ins.
On my smaller keyboards Ins is never far from anywhere :)
But also, I use sticky keys (the accessibility feature), so even on my larger keyboard I don't find moving my hand to reach the Ins key to be a problem. If I still had the real bad habit of long ago of using ulnar deviations to hit multiple keys together though, then the Ins key would probably hurt my hands, but then back then all typing hurt my hands so...
Much easier would be to have all apps treat C-S-C as copy and C-S-V as paste like the terminal does. In Chrome this starts the inspector. I changed jobs and went from a Mac to Linux and muscle memory keeps tripping me.
I don't even have an fn key, much less an insert, on my hacked-up Chromebook, so I have right-alt set to alt-gr and I mapped alt-gr+enter to insert (and alt-gr+backspace to delete) in my X key map, and, even still, it honesty feels very ergonomic to hit ctrl/shift-insert?
(FWIW, the real problem is that the behavior is inconsistent with respect to what it pastes from :/. Notably, Firefox does something unusual and there has been a bug open for over two decades to fix it... before you say "well then, go submit a patch", someone did, lol omg.)
In Emacs if CUA mode is on, C-c behaves as copy if any text is selected (and if no other keys have been pressed within a short time). To send a C-c when text is selected you do a C-S-c instead. Similarly in Windows Terminal I remember C-c works as copy without any issue (it deselects the text with the first C-c IIRC, so if you do two C-c's with text selected you copy and then send an interrupt).
Do any linux terminals implement anything like this? Why resort to adding new keys to keyboards?
The best way to solve this is to use win+c for copy and win+v as paste, as it's Mac doing. However making this ubiquitous in the system is impossible, that's why when I moved to Mac in my work, I have trouble using Linux in my laptop
> To trigger the copy or paste keyboard actions, software has to bind these key codes to actions. Software toolkits or apps themselves are responsible for this.
If only the universal subset of communication maintained by the OS were actual actions
instead of some universal shortcuts, i would prefer to have another meta key, that we finally can do another-meta+ctrl+alt+ascii for more combinations :D
universal shortcuts are overrated and get in your way anyway :D
Wouldn't it be darn nice, though, if there was a universal mechanism for apps to announce which shortcut they have available and a centralized way to configure them all?
For example, I was able to assign copy/paste keys to the corresponding actions in the GTK keybindings, and it worked like charm, except in Chrome. That is, in Chrome, web content respected these keybindings, but the browser UI didn't. So I could use the keys on textareas and inputs all I wanted, but paste into the address bar? Nooooo, BECAUSE FUCKING CHROME HAS THEM HARDCODED per platform!
(However, in Firefox it worked just fine across the whole UI.)
> But what if there were hidden shortcut combos for copy and paste on Linux that work across most apps without adding any additional software or configuration? By the end of 2025, this will be the case, and many apps already support them. Here's the scoop!
Really? What's the rationale here?
> The two most popular toolkits are GTK and QT. GTK added support the copy and paste keyboards in January 2025. QT also added support for copy and paste key codes the same month. I'm not sure of the first released version of the GTK toolkit that will contain the fix. For QT, it will be QT 6.10, scheduled for release in September 2025. Together, this will cover many apps built for Gnome and KDE as well as others that use the same toolkits.
... Oh.
No, I'm afraid that's not how the Linux ecosystem works. There are still GTK2-related packages in the current Ubuntu repos, and QT5 is still quite popular from what I can tell.
We already had a universal copy/paste in Linux: Mark with left mouse button, paste with middle button. This used to work for just about everything.
However, lately browsers started to ignore this when I mark the URL and try to paste it elsewhere, for example. Instead I get the old clipboard. I have to use the left button multiple times - and it works.
Falling back to Windows-style copy/paste, either with keys or pull-down menus with "copy" and later "paste" is, to me, a huge, inefficient step backwards and it's frustrating me every day.
Addon:
For purely non-mouse work, think serial terminal, I for one want Emacs bindings. Though that's typically configurable for the shell anyway, so everyone can choose what they prefer.
I think the multiple clipboards are great. My only regret is that there aren't more of them. Three would be excellent. But having multiple is very good, both for the pattern of "paste one thing over and over again, interspersed with copying and pasting other things" and for the pattern of "copy 1; copy 2; paste 1; paste 2" or "copy1; copy2; paste 2; paste 1" with only a single application switch.
When firefox screwed up the address bar so that the left-click/middle-click didn't work right was easily the worst step down in computing for me in modern history. Initially you could recover the non-chrome like behavior with a preference but they eventually broke that too.
> We already had a universal copy/paste in Linux: Mark with left mouse button, paste with middle button.
We still have it, at least for text. I just copied the little quote above with left mouse highlight, middle mouse paste while writing this comment in Firefox in Gnome 48 with Wayland. I use it a lot on the terminal.
What doesn't appear to work anymore (at least in Wayland) is copying a selection as a bitmap into a bitmap editor, ie. paint. Only a few decades ago that used to work, I remember that.
I wouldn’t mind an apple command key on PCs, but plug a Mac keyboard in and GUIs generally configure it as “super” usually meaning window actions rather than commands. If we could set that as a command key under the thumb I’d like that.
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.
> 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).
+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.
> 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 :)
> 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.
> 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.
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
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?
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.
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.
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.
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
> 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 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.
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...
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
Since Toshy is emulating Mac behavior, I imagine that copy/paste shortcuts move from the Ctrl key to the Super key.
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.
Also Emacs keybindings. Being able to use your text editor muscle memory for editing in every text field of every native app is fantastic.
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.
> 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
> 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.
> 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.
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.
(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.
> 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
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)
[dead]
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.
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.
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.
> 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.
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.
I think he meant devs of 3rd party software, not devs of the OS.
From the perspective of a user, what's the difference?
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.
> 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.
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.
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.
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.
> 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'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.
I think Apple did the right thing by keeping GUI shortcuts separate from terminal control codes.
I never understood why the Linux GUI world ran blindly after Windows and emulated every pattern, good or bad. And yes, I know that Ctrl-C/Ctrl-P for Copy/Paste are much older and came out of IBM's CUA and SAA initiatives. What matters is that with the Mac we had a clear role model how to handle this aspect of GUI cleanly but me missed it.
While we’re at it, I’m still on the lookout for IBM’s original SAA and CUA documentation. If anyone has these lying around, I’d be interested
> I think Apple did the right thing by keeping GUI shortcuts separate from terminal control codes
They are separate because they ditched terminal shortcuts and later begrudgingly brought them back. The original Mac didn’t have a control key. They added it back in 1987 because of pressure of terminal emulator programs.
You mean they successfully resisted the temptation to repurpose Ctrl, even though they were sure never to need it again. They did the right thing by introducing a new key for a new thing.
Ctrl+Ins, Shift+Ins, Shift+Del are the traditional shortcut keys that predate Ctrl+C, Ctrl+V, Ctrl+X. They still work on many Windows programs.
The problem is not the lack of alternatives but the embrace, extend and extinguish of established Ctrl-Key combination standards.
I am not angry at Microsoft because that is what they do. I am disappointed of Linux that it followed suit.
Besides that, every Mac has Ctrl and Option, the vast majority of users does not have dedicated Ins and Del anymore and I doubt they know how to use the Fn combos for that.
mostly, I use emacs keybindings for navigation.
I think of control-c/control-v as windows copy/paste
but on macos I can use command-c/command-v in terminals no problem.
Probably because of Miguel and his fascination with windows.
I use ctrl-Ins/shift-Ins and it works in my terminals and in the browser. I've not checked if it works in other apps because ctrl-c/ctrl-v always work in other apps. I'd be happy if ctrl-Ins/shift-Ins just always worked; I don't need innovation here.
Innovation would be to actually have that key on most laptop keyboards.
Almost every laptop that isn't a MacBook has an insert key. The only other manufacturer I've seen leave it out is HP, and then only on some models.
Even my tiniest keyboards have it!
For the first couple of pages I thought that the article was a gag, and {C,S}-Insert was going to be the punchline.
I use Alt-W and Ctrl-Y in the terminal, because I already use these to copy/paste on Emacs, and none of the CLI tools I use require these shortcuts.
The only issue is remembering to use Ctrl-C/V on Firefox, unless someone knows a way to remap its keybinds.
I just select text and press middle mouse button to paste (three fingers tap on trackpads). it works 99% of the time
While we're talking keyboards, what about emoji? Every messaging app has a different interface for them, some like Discord and Whatsapp allow you to use :smile: shortcuts, but the enumerated names are different across apps. I've occasionally gotten a dedicated OS emoji picker to show up on my Mac, but I don't know how.
On Ubuntu Cinnamon, I managed to create keyboard shortcuts for the 8 or so emoji I use the most by binding something called a "compose" key and modifying a .XCompose file, but it still took other config file gymnastics to make it persist between X sessions.
`Meta + .` opens an emoji picker on KDE. And you can type unicode with `Control + Shift + u`.
I've been meaning to look into this, but what I'd really love is a composer which can insert any text, emoji, or unicode character based on whatever alias I give it. I'd probably leverage more of unicode if I should hit a shortcut and type wd to summon a wave dash (〜).
Windows does a similar thing with win+. (I forget if win maps to the meta key on linuxes)
~/.XCompose might be what you are looking for.
Support varies - GTK needs an environment variable to use it and Qt (since version 5) only uses the first code point of the result. No idea about Wayland support or alternatives.
That's just regular keyboard for CJK languages. "today" -> "2025/08/15 Fri", "cry" -> ":crying_face:", etc. It's just small extension to regular "keycodes to full UTF-8 gibberish" process that input method editors handle.
There's nothing wrong if someone make ones for en, fr, de, in my opinion. Correction-plus-conversations like "hors douvray" to "hors-d'œuvre" in one key is going go be useful.
Control + Command + Space
You can also bind it to the fn key on a MacBook.
Crazy, thanks!
> I've occasionally gotten a dedicated OS emoji picker to show up on my Mac, but I don't know how.
On mine it shows up when I accidentally press the Fn key, which is very inconveniently placed where every other keyboard places the Ctrl key...
On recent-ish macOS it's Fn-E (nice and mnemonic). They recently added a bunch of Fn key shortcuts, but that's probably the most useful.
I like how Apple introduced the CMD key, with copy/paste linked to it in the terminal, leaving CTRL to work as intended. Even outside the terminal basic emacs key binding work as intended, such as c-k c-u etc
That's an arrangement I also really appreciate. But the origins are different from what most might assume.
Apple introduced copy and paste in 1983 using the command key. Microsoft later copied the idea using the control key because PCs lacked a command key [1].
X had super, meta, hyper keys before the PC's stunted set of modifiers became a standard [2]. Microsoft and the PC are rarely the origins of things, mainly because CP/M, DOS and later Windows were poor, amateurish, and incomplete copies of other systems.
[1] https://en.wikipedia.org/wiki/Cut,_copy,_and_paste
[2] https://en.wikipedia.org/wiki/Super_key_(keyboard_button)
I use Toshy along with an Apple keyboard to work around Linux distros' unfortunate Windowsiness here but I really really wish someone would release a fully fledged distro or DE put together with Apple keyboards in mind.
There's a lot of things about Apple I dislike but it's clear Microsoft's overloading of Ctrl for GUI shortcuts was a move made with complete disregard for terminal users, & one that's resulted in decades of pain for anyone regularly switching between GUI & terminal contexts, & I have to give it to Apple that Cmd was clearly designed to respect, retain & augment optimal terminal use.
OTOH, Microsoft's introduction of "menu accelerators" (Alt+*) is an incredible productivity booster (which luckily most Linux graphical toolkits have adopted).
I got to appreciate it only after I had to use macOS at work.
Somehow I got used to Ctrl workarounds in terminal emulators (just add shift). But the lack of accelerators bugs me immensely.
I've always found menu accelerators odd.
I find them a little too dependent on individual app developers word choices to have any kind of consistency across apps I use, plus I tend not to use menus for anything other than infrequent settings changes. Given that they haven't seemed substantially different to macos displaying annotations for bound shortcuts within the menus.
(admittedly I use mac in work & my personal computers at home have all been Linux since my Windows 2003 workstation died, so my knowledge of modern windows apps & their attached accelerators is rusty & I'm probably biased here)
The last windows I used was XP. But accelerators do work in Linux.
And they are not just about menus: in any modal window I can do Alt+O for Ok. And this paradigm allows discoverability, I don't need to memorize shortcuts, I just hold Alt and look for underscored letters – that's how GUI should be IMO.
It's not perfect, and if I were designing UI from scratch, I'd made this feature modal instead of allocating entire physical key for that (like they do hints in vim-like browsers).
Also lovely! I was going to look for somthing like Toshy - https://github.com/RedBearAK/toshy
> I like how Apple introduced the CMD key, with copy/paste linked to it in
As someone who switches between macOS and Linux every day, the change of control-key from CTRL to CMD is hella annoying. I am always pressing the wrong combo on macOS.
I completely agree. If only Windows also had WinKey+C/X/V as shortcuts, it would make so much sense in other Windows software too. Same with ALT+TAB and ALT+F4, CTRL+SPACE etc, these should also be handled by the win key. Then the Win/Cmd key would be assigned to OS functions, and the rest of them could be assigned to application functions, providing a clean separation.
Ctrl is different. Alt and Win don't cancel themselves when released, they are modal, and modal sucks. Ctrl is the only safe key besides Fn, so repurpose Fn if you must.
Non-Mac keyboards have a meta / “Windows” key as well, usually sitting there doing nothing.
On Linux it is often already used for window manager specific shortcuts.
They are the most common modifier key for tiling window managers. It's very likely one of the most often pressed key in my setup.
Yeah, that is the most sensible choice. OS key to interact with the OS, rest of the keys to interact with the application.
It's ancillary to this post, but I don't understand this obsession with "programmable" keyboards, at least for plain remapping of keys. There's entirely no point in doing it; the keymap / layout (not application key bindings, before that) is what gives keys meaning to begin with. Why would you care about what keycode a keyboard sends for some key? The only thing that matters is NKRO, if you want to remap modifiers; on non-NKRO keyboards the modifier keys are different in that they don't clash with other keys.
If the keyboard has some macro function, okay, I can see that being useful, in rare circumstances (in most cases you could also just do that in software.)
Meanwhile, the only way to get a keyboard that has 2 physical keys in the space where the wide caps lock key is on a "normal" keyboard is to build it myself. That key is the one completely useless key in the "core" of a regular layout, and I'd really like to be able to put 2 custom functions there (rather than just 1).
The keymap functionality in your OS is a hack because most keyboards are not programmable. I use a split keyboard in a Colemak layout, and it's programmed to send the correct keys despite them being in "different" places compared to a normal keyboard, so I don't have to mess with keymap switching on the operating system. I just plug it in and it works.
Also what you deem obsession is called ergonomics. Since a programmer uses a keyboard 100% of the time they spend in front of a computer, optimising for ergonomics is a great time investment. My symbol layer is so much more sane and comfortable than having to use Shift-number like an ape (no offence). In the home row under my strongest fingers, for example, I have "():_= which are the most common symbols in popular programming languages. My two thumbs are not wasted to press an humongous space bar, but have access to modifiers such as Shift and Ctrl instead of having to use my pinkies.
The secret to not losing muscle memory when you have to go back programming like an ape on a regular keyboard, is to choose a very different physical layout (like an ortholinear split keyboard) for your programmable keyboard. Then you're just learning another "instrument" which is spatially laid out differently than what you are used to, retaining your memory of QWERTY on a regular keyboard.
That's a matter of perspective. Sure, the keyboard could know the labels printed on it and send the proper key, and you could see it as "change my labels, change my keyboard's understanding of the labels and send the right thing".
Or, you could see it as "the keyboard is an input device with about a hundred possible actors, that have something printed on them to help the user distinguish". An input device's function —even if it is a keyboard— is being an input device, not necessarily inputting letters or keys. If I want to map the key labeled "U" to bring up the second last terminal window, that's valid. Not being able to input "U" now is my problem to solve. And a programmable keyboard, as programmable as it might be, can never cover the undefined set of things users around the world would want to make some keys do. So you'd have to split it in two remapping operations. But why? It's added complexity and confusion.
In your specific case, my position (which, yes, because it's not how things work in USB/BT/…, is somewhat meaningless) is that there should be a function where the keyboard reports both the labels on its keys as well as the physical layout. (And then keypresses relative/in reference to that.)
And the thing that kinda drives my position home is an annoyance a lot of German (QWERTZ) and French (AZERTY) people know: Game inputs quite commonly use WASD layouts, and those get warbled quite a bit. As they would (even worse) on your reprogrammed Colemak layout.
P.S.: your "ergonomics" and "use a very different layout" points seem to have misunderstood my position/argument. I'm saying remapping keys / different layouts should be a general OS/software function, not something the keyboard does in its microcontroller. I'm entirely on board with "fancy" layouts.
> there should be a function where the keyboard reports both the labels on its keys as well as the physical layout
You can move the keycaps around, though you'll find they don't all have the same height. Or wait until someone releases a keyboard with a small e-ink display in each keycap that doesn't cost an arm and a leg.
QWERTY is not a problem. I have a dedicated layer just for games, which is actually a QWERTY/Colemak hybrid. The left side is QWERTY, as most game keys are bound near WASD, while the right side matches closely my Colemak key maps, so whenever I have to write text in QWERTY mode, I just have to mentally map from QWERTY the left-side. In practice, this is not a problem. Non-rebindable games are just small indie ones I find on itch.io that only use WASD. The rest that have in-game text chat I rebind, and Colemak anyway is very close to QWERTY not to make that effort too onerous. 99% of games are just WASD + TEF.
Re: QWERTZ and AZERTY: those are abominations and shouldn't exist. I use QWERTY everywhere + a dedicated Compose key for diacritics.
This is my layout: https://imgur.com/a/TpJMTBH
I can't help but notice nothing you're arguing is in relation to which part of the system should be doing the mapping from abstract keys to actual letters. As such I don't see anything to engage with…
(It's also a bit strange that you argue your freedom of choice to use Colemak and then immediately proceed to call two other layouts "abominations and shouldn't exist". And this is where I'm cutting my participation in this course, because even though I absolutely agree they exist, I'm not interested in discussing objective advantages of keyboard layouts over each other. If you're arguing ergonomics, you need to accept that for a lot of people the thing they're used to is the most ergonomic because the cost of adjustment far outstrips the benefits.)
Some programs are poorly behaved (Wayfire used to be this way) and directly read keycodes rather than keysyms.
I mean, yeah, sure, but how is it a sensible fix for that to change the hard-/firmware rather than to fix those programs?
I used stty to make interrupt ktrl-k, then configured the terminal app to make copy/paste ctrl-c/ctrl-v.
I use copy/paste more than I use interrupt.
I hated MacOS keyboard shortcuts at first, but cmd-c/cmd-v do work around this problem.
Lovely. Do you have some tips for that? Something you put in bashrc?
Ctrl-Ins for copy, Shift-Ins for paste, is something that works everywhere in a graphical desktop, including my (KDE Plasma 6 Konsolepart) terminal. AFAICT the clipboard is the same.
Not enough people know that you can just select text then middle click somewhere to paste it. No keys required and yes it works with all terminal emulators I've tried. This has been default behaviour on Linux desktops for as long as I've used it (decades).
The problem with this (and to me it's a super annoying problem - marking and pasting with left and middle button is super fast and efficient) is that some browsers (or maybe it's the toolkits behind them) start to either ignore this functionality or force you to repeat the action before it works.
Yeah, I've noticed this with "some browsers" (ie. Chrome).
It's reason enough for me to stick with Firefox.
I'm almost exclusively using firefox and I encounter it on some websites and not others. In particular selection in code boxes is the thing that often doesn't work. So I suspect it's actually not the browsers but some websites playing weird js shenanigans.
Depends what you mean with "to select something"; for example if you click on the URL bar in Firefox then all the text is automatically selected. Should that count as the user "selecting" something? Perhaps not? None of this is very straight-forward.
If I do that in a Chrome-based browser, the text looks like it's selected, but it isn't. Same if I just mark the text using the left button. It won't paste when I click the middle button. I have to click again, then double click, and then it'll paste - most of the time.
Elsewhere I either double-click on a word, which will select that word for pasting, or I mark a section with the left button (press and hold at the beginning of the selection, move and release). And the middle button will paste. And paste again, if I wish.
But URLs in Chrome-based browsers instead behave in the annoying way described above. In the past it worked as expected.
The fact there is a totally different way to copy text in the terminal is the issue, it just breaks the common mental model. Even worse, this shortcut _requires using a mouse_, and not just for copying, also for selecting!
X has had two clipboards for longer than I've been using it, which is nearly three decades.
If your mental model of clipboard interaction only involves a single clipboard, and you use X, your mental model is simply wrong.
Sure, you could change X to match your mental model, but now you've broken the mental models of everyone who actually learned to use the software. And one more useful feature that makes X nice to use gets sacrificed to please the people who came from Windows but desperately want everything to work like Windows.
How would you be copy/pasting in a terminal emulator without a mouse?
Any time I've seen someone do it it's: mouse to select, keyboard to copy, mouse to select other place, keyboard to paste.
I cringe every time because it could be just: mouse to select, mouse to select and paste it in the other place with one click.
MacOS has for me the best basic keybindings even thanks to the keyboard hardware design and the fn button placed on the left side, which is the right one, as it opens the door to have home/end/pgup/pgdown with fn + arrows, and high ie perfect for 65% keyboards, I’ll never understood why pc keyboard and mech ones have the fn on the right side, totally useless.
Another thing MacOS did it right, cmd+c/v for copy/paste. Anyway, I talked about this here: https://www.paolomainardi.com/posts/linux-remapping-keys-wit... and how to remap with Xremap.
Linux already has (or had) a universal copy paste: selection and middle click.
Maybe depends upon the DE/WM you are using.
UN*X has 2 copy/paste buffers and they both work on Slackware with a Window Manager under X11 as you mentioned. I think the same is true with DE.
Is that not the case with Wayland ?
Anyway, I always liked how these worked when compared to Microsoft. Again, I do not what to see this change.
Plus we already have enough keys on our keyboard. I think Microsoft is in the process of adding an AI key, crazy. I do not look forward to 1000 keys on a laptop keyboard, already I fat finger the current keyboards too much.
For those running Sway on a MacBook, here you go:
``` # Copy-Paste re-implementation for Mac Keyboard
set $mod Mod4 bindsym --to-code $mod+z exec wtype -P XF86Undo bindsym --to-code $mod+Shift+z exec wtype -P XF86Redo bindsym --to-code $mod+x exec wtype -P XF86Cut bindsym --to-code $mod+c exec wtype -P XF86Copy bindsym --to-code $mod+v exec wtype -P XF86Paste ```
Where mod is the cmd key. It works well in most apps. At least in those I care about (terminal, browser, vim). Took me a very long time to find this solution, as a macOS refugee.
Not necessarily a MacBook, by the way. I have an Apple Keyboard with my PC (just a great keyboard I enjoy), so it works there too.
For future reference, on HN you can format code snippets by indenting it (that is, to say, indenting every line) by two spaces:
Oh, thanks, I didn’t know how to do that, and since you fixed it already, I’m going to keep it as it is, for others to know too.
Been a linux user since 2016 when I found an Ubuntu 16 installation CD in a drawer wirh old books. The thing for me is having ctrl+v paste without formatting. (If I need to retain formatting, I will gladly do ctrl+shift+v)
Maybe it's just me but, I'd gladly scroll endlessly looking at pictures of old keyboards / HID devices. (I use a Fellows KU-9938 Split Keyboard and a Kensignton)
We gonna get support for keys that don't exist on any modern keyboards, don't worry though you can remap them or bind them to change mplicated macro layers in your expensive mechanical keyboards.
Do all that and you won't need those two lines of xinit.rc
Has no one noticed that ctrl-Ins/shift-Ins are almost universal, and they work in Windows and on Linux?
Ins just doesn't exist on a lot of laptop keyboards, which kind of limits adoption.
Even when the Ins and Del are there, they're at the far right top of the keyboard, which requires moving the hand to reach them every time.
It used to be less of a hassle when those shortcuts first appeared (with IBM CUA), as Ins/Del were just slightly above the arrow keys that you'd use to select the text prior to copying/cutting it anyways.
Isn't it healthier to use keyboard shortcuts where the modifier key and the modified key use different hands?
Yes, but GP didn't imply that they would hit ctlr-Ins/shift-Ins with the right hand. GP complained that the right hand has to move a fair bit to reach Ins.
On my smaller keyboards Ins is never far from anywhere :)
But also, I use sticky keys (the accessibility feature), so even on my larger keyboard I don't find moving my hand to reach the Ins key to be a problem. If I still had the real bad habit of long ago of using ulnar deviations to hit multiple keys together though, then the Ins key would probably hurt my hands, but then back then all typing hurt my hands so...
It exists on every laptop I've had in the past decade, and on every keyboard I've ever owned. (I'm just not a Mac user.)
Much easier would be to have all apps treat C-S-C as copy and C-S-V as paste like the terminal does. In Chrome this starts the inspector. I changed jobs and went from a Mac to Linux and muscle memory keeps tripping me.
Hopefully not UI designer!
ctrl/shift-insert?
With many laptop vendors placing the insert key in the least ergonomic location or on FN layer, it's not really an option, unfortunately
I don't even have an fn key, much less an insert, on my hacked-up Chromebook, so I have right-alt set to alt-gr and I mapped alt-gr+enter to insert (and alt-gr+backspace to delete) in my X key map, and, even still, it honesty feels very ergonomic to hit ctrl/shift-insert?
(FWIW, the real problem is that the behavior is inconsistent with respect to what it pastes from :/. Notably, Firefox does something unusual and there has been a bug open for over two decades to fix it... before you say "well then, go submit a patch", someone did, lol omg.)
Rite? But no, apparently you and I are the only ones who know this.
[dead]
In Emacs if CUA mode is on, C-c behaves as copy if any text is selected (and if no other keys have been pressed within a short time). To send a C-c when text is selected you do a C-S-c instead. Similarly in Windows Terminal I remember C-c works as copy without any issue (it deselects the text with the first C-c IIRC, so if you do two C-c's with text selected you copy and then send an interrupt).
Do any linux terminals implement anything like this? Why resort to adding new keys to keyboards?
I have a mouse with an interesting number of buttons. (Elecom EX-G Pro; I recommend it if you have large hands and like thumb trackballs.)
So I ran xev to see what buttons they mapped to, and chose:
"xvkbd -text "\[XF86Copy]"" m:0x0 + b:8 "xvkbd -text "\[XF86Paste]"" m:0x0 + b:9
which my fingers have learned work everywhere except Chrome. Thanks, Google.
The best way to solve this is to use win+c for copy and win+v as paste, as it's Mac doing. However making this ubiquitous in the system is impossible, that's why when I moved to Mac in my work, I have trouble using Linux in my laptop
One thing I like is to set CapsLock to "switch to English". No need to think what language I'm at, just click it idempotently.
Besides, CapsLock is the most useless key anyway.
> To trigger the copy or paste keyboard actions, software has to bind these key codes to actions. Software toolkits or apps themselves are responsible for this.
If only the universal subset of communication maintained by the OS were actual actions
instead of some universal shortcuts, i would prefer to have another meta key, that we finally can do another-meta+ctrl+alt+ascii for more combinations :D
universal shortcuts are overrated and get in your way anyway :D
Wouldn't it be darn nice, though, if there was a universal mechanism for apps to announce which shortcut they have available and a centralized way to configure them all?
For example, I was able to assign copy/paste keys to the corresponding actions in the GTK keybindings, and it worked like charm, except in Chrome. That is, in Chrome, web content respected these keybindings, but the browser UI didn't. So I could use the keys on textareas and inputs all I wanted, but paste into the address bar? Nooooo, BECAUSE FUCKING CHROME HAS THEM HARDCODED per platform!
(However, in Firefox it worked just fine across the whole UI.)
Double-click then middle-click
How much more universal could it get?
The mark/splat functionality is one of the things that drew me to early linux...
With the author's Corne keymap, wouldn't holding down the backspace key to access the "raise" layer start deleting text?
It's a 'tap-hold' key, so the "tap" functionality is activated separately from its "hold" functionality.
Though, in order to get the same effect as "hold down backspace", e.g. QMK lets you have "tap then hold" as a way of invoking that functionality.
I thought "finally, Linux is adopting CUA", then realized this was a stealthy ad selling me remappable keyboards.
I just remap my terminal to have Ctrl-X to send SIGHUP, and Ctrl-C to copy. X looks more like a kill to me anyways.
> But what if there were hidden shortcut combos for copy and paste on Linux that work across most apps without adding any additional software or configuration? By the end of 2025, this will be the case, and many apps already support them. Here's the scoop!
Really? What's the rationale here?
> The two most popular toolkits are GTK and QT. GTK added support the copy and paste keyboards in January 2025. QT also added support for copy and paste key codes the same month. I'm not sure of the first released version of the GTK toolkit that will contain the fix. For QT, it will be QT 6.10, scheduled for release in September 2025. Together, this will cover many apps built for Gnome and KDE as well as others that use the same toolkits.
... Oh.
No, I'm afraid that's not how the Linux ecosystem works. There are still GTK2-related packages in the current Ubuntu repos, and QT5 is still quite popular from what I can tell.
So what ARE the key codes for dedicated copy and paste keys?
On Linux, they map to XF86Copy and XF86Paste. There's also XF86Cut and XF86Undo.
You can bind these on Emacs, for example.
We already had a universal copy/paste in Linux: Mark with left mouse button, paste with middle button. This used to work for just about everything. However, lately browsers started to ignore this when I mark the URL and try to paste it elsewhere, for example. Instead I get the old clipboard. I have to use the left button multiple times - and it works. Falling back to Windows-style copy/paste, either with keys or pull-down menus with "copy" and later "paste" is, to me, a huge, inefficient step backwards and it's frustrating me every day.
Addon: For purely non-mouse work, think serial terminal, I for one want Emacs bindings. Though that's typically configurable for the shell anyway, so everyone can choose what they prefer.
I think the multiple clipboards are great. My only regret is that there aren't more of them. Three would be excellent. But having multiple is very good, both for the pattern of "paste one thing over and over again, interspersed with copying and pasting other things" and for the pattern of "copy 1; copy 2; paste 1; paste 2" or "copy1; copy2; paste 2; paste 1" with only a single application switch.
When firefox screwed up the address bar so that the left-click/middle-click didn't work right was easily the worst step down in computing for me in modern history. Initially you could recover the non-chrome like behavior with a preference but they eventually broke that too.
> We already had a universal copy/paste in Linux: Mark with left mouse button, paste with middle button.
We still have it, at least for text. I just copied the little quote above with left mouse highlight, middle mouse paste while writing this comment in Firefox in Gnome 48 with Wayland. I use it a lot on the terminal.
What doesn't appear to work anymore (at least in Wayland) is copying a selection as a bitmap into a bitmap editor, ie. paint. Only a few decades ago that used to work, I remember that.
We still have it, it's just that we don't have it everywhere anymore. Which truly breaks up the workflow, or how I do things.
I wouldn’t mind an apple command key on PCs, but plug a Mac keyboard in and GUIs generally configure it as “super” usually meaning window actions rather than commands. If we could set that as a command key under the thumb I’d like that.
“The Year of the Linux Desktop” will be when copy/pasted is solved.
What about cut?
Cut also has a dedicated keycode. See https://news.ycombinator.com/item?id=44911608
[dead]