Hacker News Reader

Comment by quesera | Hacker News Reader

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

View on HN

The difference was that Mac keyboards had an extra modifier (pcs had ctl alt and shift, Macs had opt ctl cmd shift) key and pcs generally did not until the windows95 era.

I have linux (pop os) running directly on a macbook (basic dev work), and the different key combo for copy paste in terminal is one of my very few issues.

debating with myself whether to remap keys (and then fumble on other linux terminals), or to just learn the new key habit.

Checkout my project before going around and remapping all of your keys.. Kinto doesn't do anything like that. It will actually do all of the remappings you want via a single config file that you can easily add on to if you really need (I doubt it though) & you can disable it or uninstall it at any time. https://github.com/rbreaves/kinto or http://kinto.sh

Copy/Paste in terminals is one of my greatest Linux peeves. It’s one of those things that just doesn’t stick… I can swap between Ctrl and Command all day but throwing Shift in there screws it all up. Eventually I just started right-clicking in Linux terminals for that particular functionality.

Same, and as I mentioned above, writing this was my solution. https://github.com/rbreaves/kinto or http://kinto.sh

Question: does Ctrl+Insert (copy) and Shift+Insert (paste) work in MacOS? (reason: I mostly copy/paste that way in Linux&Windows, in both shells and apps - I don't have a Mac)

Unluckily nowadays some notebooks don't have an insert-key, which makes me sad.

Question: does Ctrl+Insert (copy) and Shift+Insert (paste) work in MacOS?

No. Mostly because Apple keyboards don't have an Insert key.

(They do have a "Clear" key, which I wish more developers would support. But I think so many are on the laptop or small keyboard they don't realize all the buttons that are available.)

That's a convention per the app mostly and apps on macOS just don't need to use it.

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.

So let's not convince you, you can still experience what it is like to have a potentially better hotkey layout via my project if you want to try it out.

https://github.com/rbreaves/kinto

great post! ty

Reply on news.ycombinator.com