Do all that and you won't need those two lines of xinit.rc
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.
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...
(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.)
The only issue is remembering to use Ctrl-C/V on Firefox, unless someone knows a way to remap its keybinds.
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.
I don't think anything has caused me more pain with computing than this.
And I'm including dealing with Python dependencies.
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.
"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."
set clipboard=unnamedplus
"add"+p
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.
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.
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.
"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.
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’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.
> 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.
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.
> 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.
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.
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 +)
BTW, text selection in terminals seems much more annoying to me, than the necessity to press Shift when copying.
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
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
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.
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.
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.
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.
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 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.
Well, it is a surprise to me. You claimed terminals were "just text". You said you taught this to beginners.
It is not surprising to me that those beginners would have difficulties understanding what was going on when terminals started demonstrating that they were indeed more complex than pure text.
> But would I be okay if a good redisgn stopped it from working with physical type writers hooked up to main frames or from talking telnet to my oscilloscope?
If we did that, they wouldn't be terminals anymore. They'd become some new, incompatible system that exists alongside the old school terminals.
I'm not even opposed to it. I love the idea of reimagining and reinventing everything. We just gotta recognize that we're building new systems. The old ones should probably be left alone.
Modern terminal emulators like kitty are working miracles out of this legacy stuff but they are still working within the confines of the system.
> I know that this is not a simple change, but it is 2025 and we can think about how things should be instead of staying with how they always have been without reason, especially if we are just talking about the defaults.
The legacy of terminals is useful even today. Embedded debugging interfaces use them. I wear a modern open source watch which supports a shell through the terminal system. There's just no getting rid of it.
Even swapping Ctrl-C and Shift-Ctrl-C seems like we're just moving the inconsistencies around. Sure, copy paste is now consistent with modern interfaces but now the inputs no longer correspond directly to ASCII. Maybe we could have a vim-like modal interface where in GUI mode all the key combinations would do what we expect from modern systems while in terminal mode they would act like ASCII inputs. This fixes both inconsistencies... At the cost of being an error-prone modal interface.
The 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?
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.
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.
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.
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.
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].
It does. However, spending time remembering which of the different weird buffers something is pasted into is not being efficient.
It's a feature you're not accustomed to.
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.
> 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.
> The end.
Does it fix the issue with the multiple buffers and minor annoyances?
No. It just adds a different friction point.
The end.
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.
* 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)
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.
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
It's likely that the users who find this annoying will simply stop using Linux.
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.
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.
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've lost countless SessionManager terminal sessions this way on Windows and Linux.
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...
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.
> 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.
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.
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.
We use copy on select... what's all of this keyboard shenanigans /s
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.
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)
> 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.
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.
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.
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.
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
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-...
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
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...)
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?
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.
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).
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...
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?
> 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 :)
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 :)
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 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.
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.
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.
anyone know the differences?
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.
I've just tried: Open Notepad; write something, select and copy it. Exit Notepad. Open browser. Paste. What was written in Notepad gets pasted.
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).
* 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.
You have to know what to add. Sometimes it is shift, sometimes (rxvt) it is alt.
> 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.
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)
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.
It's reason enough for me to stick with Firefox.
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.
If only the universal subset of communication maintained by the OS were actual actions
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.
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.
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...
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'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.
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.
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.)
Do any linux terminals implement anything like this? Why resort to adding new keys to keyboards?
universal shortcuts are overrated and get in your way anyway :D
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.
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 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.
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.
You can bind these on Emacs, for example.
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.
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.
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.
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
(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.)
How much more universal could it get?
The mark/splat functionality is one of the things that drew me to early linux...
Besides, CapsLock is the most useless key anyway.
``` # 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.
# 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 XF86PasteReally? 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.
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.
meitham•5mo ago
rafram•5mo ago
samlinnfer•5mo ago
cycomanic•5mo ago
lucideer•5mo ago
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.
koiueo•5mo ago
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.
lucideer•5mo ago
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)
koiueo•5mo ago
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).
biehl•5mo ago
AnonymousPlanet•5mo ago
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)
louthy•5mo ago
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.
npteljes•5mo ago
childintime•5mo ago
npteljes•5mo ago