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
> 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.
> 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.
> 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.
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.
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.
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.
> 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 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.
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.
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?
> 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.
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.
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.
My biggest annoyance by far is that select on multiple browsers location bar does let you middle click paste the selection. You have to copy and paste.
I'm not sure I've seen the sci-fi movie where Apple is heralded as the golden standard of key bindings, but having used Macs for a few years in real life, I can attest the key combinations are an absolute atrocity for the reasons you mentioned and then some.
While I grew to accept some advantages of my Mac can't be easily replicated in other platforms, I think it is severely lacking in basic features, user experience and it's still occasionally infuriating even in 2025.
I do have a very long list of Mac gripes, as is probably deductable from this comment.
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 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.
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.
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.
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.
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.
Readit News
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.
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.
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...
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.
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.
BTW, text selection in terminals seems much more annoying to me, than the necessity to press Shift when copying.
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.
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.
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.
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.
It's likely that the users who find this annoying will simply stop using Linux.
We use copy on select... what's all of this keyboard shenanigans /s
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.
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's literraly breaking your muscle memory for one of the most commonly used shortcuts for no reason. It's a pretty big ergonomic blunder
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.
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?
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.
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.
* 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.
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.
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
> 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 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 don't think anything has caused me more pain with computing than this.
And I'm including dealing with Python dependencies.
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)
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.
You have to know what to add. Sometimes it is shift, sometimes (rxvt) it is alt.
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.
"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.
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.
> 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.
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.
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 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
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.
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 think of control-c/control-v as windows copy/paste
but on macos I can use command-c/command-v in terminals no problem.
The only issue is remembering to use Ctrl-C/V on Firefox, unless someone knows a way to remap its keybinds.
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.
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.
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.
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...
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)
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.
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.
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.
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).
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.
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.
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.
It's reason enough for me to stick with Firefox.
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.
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.