> And don't get me started on the completly stupid difference between ctrl+c and cmd+c. One (the standard for everything except macos) is used in terminal and the other in every other app.
This is completely backwards.
In Linux, Copy/Paste is Ctrl+Shift+C/V in various terminal programs, but Ctrl+C/V in other GUI programs
In MacOS/OSX/macOS since 1984, Copy/Paste has always been Cmd+C/V. ...because Copy/Paste are OS/GUI shell actions, and Control characters are not the same thing.
Microsoft broke this separation in Windows 1.0, and Linux has stupidly aped Microsoft ever since.
See also: Microsoft/Linux dialog boxes where the "Continue forward" option is located on the LHS (which in most locales notably including the original context, means "move backward").
Windows 1.0 was 1985, so a difference of a year is a bit silly. The majority of the world uses CTRL-C/V and has for decades, so that's the standard.
The use of Ctrl+C as a control character, to mean "ETX/end of text" goes back to ASCII at least, so 1960. And as Cancel/Interrupt to the late 1960s at DEC and of course Bell/UNIX.
Apple (really Xerox/PARC in this case) needed a key combination for "Copy" in their first GUI, and decided not to break the usability of that preexisting standard (and all of the other Control chars, some of which are still useful today).
Microsoft Windows came along shortly afterward. They copied Apple/Xerox's choice of C/X/V for Copy/Cut/Paste in the GUI, but they broke the well-established standard meaning of Ctrl+C in the process. (IIRC, this is especially ironic because they were also breaking the meaning of Ctrl+C from MS-DOS.)
And sure, Microsoft then went on to become dominant, and by virtue of their dominance created a huge number of people who believe that the misuse of Ctrl+C for Copy is "standard".
But it still breaks functionality. Then and today, 35+ years later.
"Copy" should be the same action in all applications. If it is not, the OS/GUI is failing the user.
As per usual though, Microsoft mostly will let you do what you want the way you want to do it by giving you an option, while Apple is busy breaking your things and trying to convince you that theirs is "the one true way". Here's the Microsoft option for letting you use Ctrl+C to copy in their terminal - https://www.howtogeek.com/howto/25590/how-to-enable-ctrlv-fo...
If you want the same on Linux, it's available.
But Ctrl+C to Copy is the broken part, so I do not want it! :)
Ctrl+C is a signal to the running application inside the terminal, and should be passed without interference by the terminal emulator.
> Apple is busy breaking your things and trying to convince you that theirs is "the one true way".
If by that you mean "doing things the reasonable way and not needing to offer workarounds for their failures", then we are in complete agreement. :)
I want OneModifierKeyButNotCtrl+C to Copy in all GUI applications including terminal emulators. I would settle for SomeModifierKeyCombinationNotCtrlAlone+C to Copy in all GUI applications including terminal emulators.
I don't know if Microsoft offers that, but Linux does not. Copy/paste between a web browser and a terminal window is an exercise in frustration.
> But Ctrl+C to Copy is the broken part, so I do not want it! :) Ctrl+C is a signal to the running application inside the terminal, and should be passed without interference by the terminal emulator.
No, detecting when some text is selected and performing a copy instead of sending the signal is the correct way to do this in 2020.
If you don't like that, every OS lets you remap keys.
> If by that you mean "doing things the reasonable way and not needing to offer workarounds for their failures", then we are in complete agreement. :)
I guess next you'll be telling me that never implementing a real "maximize" feature for application windows in your OS is reasonable. :) (And no... Alt + click on the green button does not maximize every window.) As usual, with a Mac you have to continually work around Apple by using apps that will probably not work after a big update if you want to do anything out side of the "Apple way".
> I want OneModifierKeyButNotCtrl+C to Copy in all GUI applications including terminal emulators. I would settle for SomeModifierKeyCombinationNotCtrlAlone+C to Copy in all GUI applications including terminal emulators.
And you can absolutely have that in Windows or Linux [0]. That's because both of them are easily orders of magnitude more flexible and have more options than any OS offered by Apple. Heck, I can't even turn off that idiotic marketing tactic of old, the startup chime, in my old 2012 Mac Pro.
Anyway - whatever you think is correct about Ctr+C, there's no denying that Macs are completely inflexible in many, many, many ways and the only reason you're on one if you've got strong opinions is because your opinions happen to align with what Apple thinks. If your opinion differs at all, you'll be the one bending. Enjoy that!
[0] https://www.google.com/search?q=change+copy+paste+shortcuts+...
> No, detecting when some text is selected and performing a copy instead of sending the signal
Ugh, that sounds awful! The Copy action should always be the same action, and it should always copy only, and never do unexpected, possibly harmful, things.
Re: Maximize. FWIW I have always preferred the OSX implementation -- it allows me two different window sizes that I can choose myself, and toggle between them. But I'll concede that if you come from Windows, having one of those choices taken away from you feels more natural. :)
Re: OneModifierKeyButNotCtrl+C. I can't speak for Windows, but this does not work on Linux. You can screw around with xmodmap and some apps to your heart's content, but you will never configure a GUI/DE-wide key combination for Copy that works in all apps. This is what you get, for free, on all versions of MacOS, ever.
Unless your argument devolves to "source code is available". In which case: OK I guess.
Re: macOS inflexibility. I mean, sure. And sometimes flexibility is critical. Other times, carefully-chosen defaults and strong consistency is more important. Anyway Linux's flexibility does not provide a path to solve this specific UX design error, so it doesn't help me here.
Don't get me wrong. Linux is great, and I choose it and use it happily for many things. I choose other OSes (all Unixes though!) for other purposes.
I have specific requirements for my desktop/console/terminal environment which might not match yours. MacOS meets them with default configuration plus some minor tweaks (e.g. focus follows mouse). Linux is not flexible enough to meet those needs, so I do not choose it for that purpose. All good.
> This is what you get, for free, on all versions of MacOS, ever.
You're trading one slight discomfort (in your opinion) for a thousand others because the rest of macOS is abysmal. There's hidden, undiscoverable functionality everywhere, the window management is absolutely disgusting, the file management is sorely lacking, the amount of tweaking you have to do to get decent terminal utilities is sickening, the hardware choices are extremely limited and the tyrannical company that builds it works regularly to own you.
No amount of rationalization will convince me that it's a good OS for anything other than building iOS apps.
Thankfully at least I can run a better OS on the hardware once Apple stops supporting it. Unfortunately I still must jump over many Mac hardware obstructions just to get something resembling a normal BIOS so I can even boot something else. It's just disgusting when I have to do it. At least I never gave Apple any money though since I buy it all used.
They are the China of the technology world and I wouldn't be proud to support them at all even if their desktop OS was actually desirable. Still, they own half (or more) of the phones in use in the US so I have no choice but to deal with them.