Hacker News Reader

Comment by krzyk | Hacker News Reader

> Certainly no encounters with a "weird security system"

You didn't use mac during the notarization system outage? I coulndn't even use my keyboard and mouse (the one on macbook, NOT bluetooth one) for 2-5 minutes after lid was opened.

Never had such issue with Linux, yeah, bluetooth ones might stop working but wired keyboard (or laptop open) works always.

Yesterday out of the blue my wifes AirPods Pro stopped working with macbook AND iPhone at the same time - they rejected connection (or actually on mac it looked like they are connected but the sound was coming out of speakers not the pods) and the same situation with iPhone. I had to reset AirPods to make it work.

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.

For me macbook would be great for one thing: installing Linux on it, if it only had the ctrl key in the correct place (that is at the left corner of the keyboard not next to Fn).

View on HN

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

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

You didn't use mac during the notarization system outage? I coulndn't even use my keyboard and mouse (the one on macbook, NOT bluetooth one) for 2-5 minutes after lid was opened.

True that this is a good example of a security system that affected people negatively – though ironically I was unaffected by this because I was on-site with a customer, working on an annoying network without internet connectivity. But yes – it's fair to say the ecosystem is not perfect.

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 not "completely stupid" – it's just a difference between platforms. The command key sends commands, and the control key sends control codes. The cmd+c combination will copy text in both the terminal and all other applications; ctrl+c will send an interrupt. If anything, this is one of the things that keeps tripping me up working on a Linux desktop after so long – I keep inadvertently sending ctrl+c instead of copying, because the control key is overloaded with both text manipulation commands and control characters! But this is just a muscle-memory and familiarity thing.

I have found it convenient that in both Linux and Mac terminals, highlighting text copies it, and middle-click pastes. I expect this is one reason why ctrl-c-for-copy isn't as much of a problem as you'd expect on Linux: most people copy/paste with the mouse only.

> You didn't use mac during the notarization system outage?

This has happened literally once in the history of macOS.

> And don't get me started on the completly stupid difference between ctrl+c and cmd+c.

Ctrl-C and Cmd-C are completely different actions. What is weird is that some OSes use the same keyboard combination for them.

You know, this is about the one thing I do like about macOS. Cmd+C/V should indeed be the universal sequence for copy/paste.

I particularly hate the way GNOME terminal uses Shift+Ctrl+C/V for this, because if you accidentally hit Shift+Ctrl+C in Chrome then it opens Developer Tools.

This is classic Linux - a herd of small furry developers all trying to pull a large heavy object in different directions while not listening to what anyone else wants because pulling on things is fun.

MacOS is a large heavy object being pulled by a mysterious force in a direction no one is sure they want to go, but at least it mostly works, kind of, on good days. Except when it suddenly changes direction and runs you over.

Windows is a large heavy object with an embedded malevolent eyeball and a huge trail of wreckage behind it. People keep signing up for more wreckage, and it's really mystifying.

I hope I am not shilling too much here , but hey you can try out my Kinto app over here if you'd like. You'll get the keymaps you want. https://github.com/rbreaves/kinto

Yeah I switched to Linux on my primary work machine a few months ago and I am still flubbing the copy paste combos between the shell and gui apps.

It’s also much more ergonomic on hands and fingers.

Go figure... I actually like that the terminal has its classic Ctrl+ characters unimpeded by the GUI layer, which has its own namespace behind Cmd+

How do you copy text out of your virtual terminal?

The Fn key placement on the other hand... I’m with you.

You select it. No further steps required.

So every time you slip slightly with the mouse while clicking, you destroy the clipboard contents.

True, but if you mess up the selection step, you won't be able to copy to the clipboard what you wanted with a keyboard shortcut, either.

No, they mean that selecting text is a common activity that doesn’t necessarily imply I want to copy it into my paste buffer. If I want to keep the contents of my paste buffer, I have to force myself to remember not to highlight anything, or I have to go back and find the original text to copy again.

The number of times I’ve accidentally obliterated important and hard-to-relocate paste buffer contents on Linux by a wayward mouse action easily numbers in the thousands.

> copy it into my paste buffer

Selecting text never copies anything. Selections are just metadata that points back to the X client app that "owns" the selection and presumably also has the selected data. Selecting text simply sets the owner of the PRIMARY selection to the current X client, and "pasting" with middle click is asks the current owner of the PRIMARY selection to copy the selected data into the window targeted by the click.

From ICCCM[1]:

>> Selections communicate between an owner and a requestor. The owner has the data representing the value of its selection, and the requestor receives it. A requestor wishing to obtain the value of a selection provides the following:

    The name of the selection
    The name of a property
    A window
    The atom representing the data type required
    Optionally, some parameters for the request

>> If the selection is currently owned, the owner receives an event and is expected to do the following:

    Convert the contents of the selection to the requested data type
    Place this data in the named property on the named window
    Send the requestor an event to let it know the property is available

> If I want to keep the contents of my paste buffer, I have to force myself to remember not to highlight anything,

You're having this problem because you're using the PRIMARY selection when you should be using the CLIPBOARD selection which is more durable and intended[2] for data transfer and copy/paste-like semantics.

The Copy/Paste actions traditionally found in the "Edit" menu usually interact with the CLIPBOARD selection. This should be completely orthogonal to the middle-click feature and other interactions with the PRIMARY selection. You should be able to mix usage of both selections. Try this:

    select text "foo"
    use Copy from the Edit menu   # CLIPBOARD now points to "foo"
    select different text "bar"   #   PRIMARY now points to "bar"
    move to an editable window
    use Paste from the Edit menu  # pastes "foo"
    middle click the same window  # pastes "bar"

Unfortunately, confusion about the X server using selections instead of a global buffer is not well explained.

[1] https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM...

[2] https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM...

The fact that you need a wall of text with multiple external sources to explain that I'm using copy and paste wrong is pretty conclusive supporting evidence in my favor.

If I have to read pages of documentation to understand how to do something that is utterly trivial and intuitive on every other major operating system, your approach is broken.

I'm just trying to help your "obliterated ... by a wayward mouse action" problem.

As I said at the end of the post, the actual behavior of some X Window System features are poorly explained and not obvious. The unexplained differences from the de fact standard behavior new users expect is as major usability problem. However...

> utterly trivial and intuitive on every other major operating system

It's worth remembering that when the standards document referenced in my previous [1] was originally written... a lot of those "major operating systems" didn't exist. In 1987, MS Windows was on version 1.0. I'm not sure it even supported any clipboard-like features. In that era, minimizing memory usage and network traffic were important, design goals.

> intuitive

"The only 'intuitive' interface is the nipple. After that, it's all learned." -- Bruce Ediger, on X interfaces

(ref: /usr/share/fortune/linux)

> I'm just trying to help your "obliterated ... by a wayward mouse action" problem.

That's fine and I do appreciate the information, but from the perspective of the overall discussion I think the point stands that the X approach to this is completely broken from a user perspective.

> It's worth remembering that when the standards document referenced in my previous [1] was originally written... a lot of those "major operating systems" didn't exist.

That's completely understandable, but we've had over thirty years to adapt. This argument is the same one that keeps Emacs greybeards defending M-k and M-y despite the fact that there hasn't been a Meta key on a single keyboard I've used in my 30 years of computing.

At some point you have to accept that the rest of the computing world has agreed upon a different standard than yours, and you either need to take steps to accommodate that or die.

That's not to say you can't try out new things while still abiding by existing standards (for instance, with advanced features like pastebuffer history), but that's completely different from clinging on to inferior historical approaches when everyone else has moved on.

If configured, sure, and if you use the mouse for all text selection. And also if configured, middle-click can paste.

Now how about Cut (Cmd+X vs Ctrl+Shift+X)?

I don't have an alternative for Cut, unfortunately. How do you select text in your virtual terminal with the keyboard?

> How do you select text in your virtual terminal with the keyboard?

with xsel(1x) or xclip(1)

https://github.com/kfish/xsel

https://github.com/astrand/xclip

tmux lets select with just the keyboard, even when tmux is on a remote server and you are using it through ssh, you can select to your local clipboard. This is for iTerm, don't know about other terminals. No idea how this works, just tested in Terminal.app and it works too.

>You didn't use mac during the notarization system outage?

No, I didn't even know it was thing until I read about it here. However, I don't use a lot of apps from the AppStore, so I dont' know if that was a contributing factor. I'm also not one to close and launch apps regularly. Terminal, Browser, TextMate are open 100% of the time. I usually have Photoshop and/or Illustrator open in the background as well. Don't be a quitter, you don't have to be a starter.

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

The Mac has had the Cmd key sincd the very first days of Apple. In fact, it was originally two separate keys: open-apple, closed-apple. It was around well before Linux was a glint in Linus' eye.

> However, I don't use a lot of apps from the AppStore

I don't have any from AppStore, besides those that are factory installed and as I wrote previously, after resume from suspend my keyboard and mouse werent' working I was thinking that this macbook just died (and it was only 1 week old).

Thank god I found out that it needed only simple block of notarization server to make this stupid "security" stop usability.

BTW. You could try to see what happens when you are far from WiFi (with poor connectivity) and try to wakup laptop from sleep - the same, keyboard and touchpad don't respond for 1-2 minutes.

Reply on news.ycombinator.com