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

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

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

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

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

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

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

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.

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

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

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.

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

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

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

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

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

> 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.

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

  set clipboard=unnamedplus

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.

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?

> 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.

> 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

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

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.

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

> Devs do not get to decide

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

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

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

I 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.

With all possible kindness...

> Devs do not get to decide

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

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

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

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

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

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

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

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

You must be new to computers. /s

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