Hacker News Reader

Comment by spankalee | Hacker News Reader

I recently got a Linux desktop after being Mac-only for a long time and using Linux only as a deploy target, and holy shit: the modifier key situation on PCs is so bad.

Control specifically is just a terrible modifier key for common things like edit commands. First, it sits near your pinky instead of your thumb, making chording it with Z, X, C, V, etc., really difficult.

But then... who decided that ctrl-c should be used for both copy and abort??? That's diabolical levels of messed up. In a terminal app ctrl-c aborts, so you need to use shift-ctrl-c to copy, and now you have two shortcuts for the same operation you need to remember based on context, except that in a web-based terminal in Chrome shift-ctrl-c opens "Inspect Element Mode" and now you have no way to copy!

Am I the only one who finds this astoundingly frustrating?

View on HN

On PC the "original" (Windows 3.0 and earlier) shortcuts for cut/copy/paste were Ctrl-Del, Ctrl-Ins, and Shift-Ins respectively. I believe these were inherited from some older IBM user access standards. And for the most part they still work in Windows, especially in command lines.

Ctrl-X/C/V were originally Macintosh (and maybe Xerox before that?) and then were adopted by Windows in the 3.1 era so Word for Windows would match up better with Word for Mac. But PC not having a Command key, and the Windows key not being a thing yet, they were applied to Control instead. Which of course overlapped with the other major use of Ctrl-C as "interrupt" starting back into early UNIX machines (and adopted by DOS) but... being a graphical environment they apparently didn't consider that important at the time.

>maybe Xerox before that?

Yes, the cut/copy/paste system and its shortcuts were developed at the Xerox PARC LRG as part of Smalltalk-76. They used a Control key.

>and adopted by DOS

DOS inherited it from CP/M by way of the 86-DOS clone that Gates purchased. Kildall used the TOPS-10 while developing PL/M and CP/M and adopted some of its conventions, including control-break.

It is indeed frustrating.

Historically, of course, copy and paste on a Unix machine was a mouse thing and followed X11 conventions. You selected text with the left mouse button — automatically be saved to the primary clipboard just by virtue of being selected, no key press needed — and the middle mouse button pasted it at the location you clicked.

This is somewhat different to having the two part motion/action of select/control-C and click/control-V. It’s boiled down to just select and middle-click. Separately, you can often use shift-Insert to paste the primary buffer.

I only recently learned that when using the MacOS trackpad with the terminal, you can simulate a middle button click to paste: Highlight some text anywhere in the console, drag it a little and let go. As you pull the text, a little green arrow will pop up and when you let go of the drag (anywhere) it'll paste the text into the prompt, just like middle click does.

Maybe everyone has known this forever and I'm the last to find out, but I thought I'd share as it was a revelation. I middle click all the time when using a mouse, so it was nice to finally discover a replacement while using the trackpad.

That's drag and drop.[1] App support is varied on this.

Alternatively, though I don't know if it works on Mac, on X11 Linux you can middle click with touchpads by tapping with 2 fingers. Tapping with 3 fingers right clicks. That's going to work anywhere clicking does, because it's handled by the touchpad driver rather than by app convention. If it doesn't work by default, it can be configured with `synclient`.

[1] https://en.wikipedia.org/wiki/Drag_and_drop

The "trick" I'm pointing out here is that you don't have to aim your drop. As soon as you see the + icon, you let go and it's pasted below, even if you've scrolled too far to actually see the active prompt.

Other than this, I don't think I've ever found a use for highlighting a chunk of text and dragging it somewhere. Maybe someone else loves it, but the risk of accidentally dropping it somewhere you don't want makes it not worth it for me.

Caps Lock remapped to control. By using a keyboard where I can remap keys at the firmware level whenever possible, and in the OS when not

Ctrl-C doing different things come from different os/software lineages

You're still using your pinky for the most common modifier, not a good alternative

But in a far more natural form.

Actually, in many cases the opposite. If you have a classical Corner control, it can be used with a part of your palm with less movement, and you finger doesn't contort

"far more natural" would be if you moved pinky up or down. Sideways movements are only natural for your thumb

I move my whole hand around a lot, both by rotating at the wrist and moving at the elbow level.

> First, it sits near your pinky instead of your thumb

It's not bad if you have a keyboard (e.g. topre) with control in the caps-lock position (or remap it, which I usually do).

And I also agree that the Lisa/Mac-style command-[zxcv] works really well (particularly if you use a mouse with your right hand.)

MacOS has no problem with both control-c (break) and command-c (copy) - why isn't this common in Linux as well (at least for keyboards with a command or windows key, which seems to be many, many keyboards.)

Of (home,end,pgup,pgdown,delete,backspace) the mac has just backspace. And they have just a single control key and such. Clearly the mac keyboard is designed by people that have no idea how to type. There's no "standard windows keyboard" anymore, but even the worst is still worlds better than whatever apple puts out.

Sorry, what are you talking about?

https://www.apple.com/shop/product/mxcj3ll/a/magic-keyboard-...

I see on that Apple keyboard:

• two control keys

• two option keys

• two command keys

• delete (aka backspace)

• forward delete (aka delete)

• home

• end

• page up

• page down

On space limited laptop keyboards yes, but you can get all of those with chording. Except the right hand control key of course.

I significantly prefer the Mac way of chording Option or Command with arrow keys to achieve those functions. One of the main reasons I can't get used to Linux desktops is that I can't use Opt-arrow to navigate by word and Cmd-arrow to navigate by line. Cmd-arrow makes much more sense than a dedicated Home and End button imho.

You're right, but it's fixable: remap Ctrl and Alt permanently with sharpkeys then do a few rebinding fixes in something lik. Autohotkey. Your main modifier should indeed be a thumbs key just like on a Mac

Ctrl-C dumb double function can also be fixed, use it to copy everywhere universally (use a better terminal with an override) and rebind cancel

> who decided that ctrl-c should be used for both copy and abort???

As usual in most of these cases, there wasn't really a single decision, just some historical artifact no one had the care to think about and fix, so it lingers in defaults

Maybe Pause key could be used for legacy "Ctrl+Z" and "Ctrl+Break" for Ctrl+C

That would require moving your right hand (potentially on your mouse) and anyway too far away and not even present on laptop keyboards...

Maybe you could use thumb+Escape for Ctrl+C?

Or thumb+X is simpler - you can't cut anything in the terminal, so "cutting" the current process is a convenient combo and even has some mnemonic potential

You could also have +C copy when text is selected and break otherwise, though that modality can be a bit confusing / error-prone for some

Nope, it is a crying shame the early Linux/Unix desktop environments copied the Windows/IBM CUA shortcuts and now we have to fight every app and every different method there is for setting keyboard shortcuts to fix it. The Ctrl key was already claimed for use in the terminal for signals and line navigation.

Toshy can help but it's still not a perfect fix.

> The Ctrl key was already claimed for use in the terminal for signals and line navigation.

First claim has no priority over better claim. Designs can and should improve

OK sure in general maybe, but that isn't what happened here. What happened is a worse design where Ctrl+C sometimes copies and sometimes kills the current process in your terminal. It's annoying and dumb and clearly inferior to what NeXTSTEP and macOS ended up doing with a separate "Super"/GUI/Command key to handle GUI shortcuts like Cut/Copy/Paste, and leaving Ctrl to handle UNIX shortcuts in the terminal. This allowed the readline/emacs text cursor navigation to also carry over into the GUI, so you can treat text anywhere the same regardless if its a GUI text editor or your terminal.

> What happened is a worse design

But the reason it happened like this is precisely your principle I argued against where some shortcut got claimed first and blocked evolution! The way easy out is to rebind Ctrl+C as kill

> allowed the readline/emacs text cursor navigation to also carry over into the GUI

That's another set of dumb defaults that should've evolved years ago but got stuck (just like Ctrl+C)

> treat text anywhere the same

Great aspiration, but I don't see how it follows that you can't change the first-claimed shortcut?

Ok but Ctrl+C didn't get rebound. What would you rebind it to?

We're having two different arguments. I am arguing what is and what exists. There are two largely systems in place: the NeXTSTEP lineage where Ctrl is left to do what it has always done for 40+ years, and GUI shortcuts live on a different key, and the IBM CUA/Windows inspired lineage where Linux DEs copied the CUA shortcuts for GUI actions in perhaps some ideal of competing with Windows, and overloaded Ctrl resulting in a shitty experience that continues to this day.

You are arguing some world that could exist that you have not really described or fleshed out beyond "well any of those keyboard shortcuts could have been different or changed". OK? Wow. Sure. We could put Copy on Super+Shift+W, we could throw away keyboards all together and use telegraph keys and Morse code. We could do anything. I don't care? Coulds are not interesting unless you're going to bother explaining why we should do some hypothetical "throw away every keyboard shortcut from the last 40+ years" and show the work of "here's a better future that we could have if we chose to". I never said we "can't change the first-claimed shortcut". You simply haven't demonstrated any reason we should.

I entirely agree. At $NEWJOB, I had a Linux laptop for a bit while a Mac was on backorder.

Not being able to cut/paste easily because every tool used the Control key for something different, especially in the terminal, was infuriating.

Having the command key handle these kinds of GUI-focused interactions, and Control for most of the terminal-centric and text manipulation (Ctrl-A/E for beginning/end of line, from Emacs) makes the system great to work with.

I didn't mind anything else about my foray into Linux as a desktop OS. If we could get a Linux GUI distro that all it did was match the Mac command key paradigm, I think it would make a lot of people happy.

Shift+Insert will let you paste anywhere. It's an IBM thing historically, I believe, and it works pretty much anywhere. Also useful for websites that try to block normal ctrl+v.

Yeah this drives me crazy too.

As a sibling comment notes, Caps Lock as Control helps a lot but it's still not as nice as Command-based shortcuts, both in hand positioning and in terms of shortcut overlap.

I use keyboards with two ctrl and two alt keys. Thinkpads and some Dell laptops have them, and of course there are external keyboards with those keys too.

> Am I the only one who finds this astoundingly frustrating?

No, you’re not. That’s why I tend to use the archaic shift-Ins and control-Ins shortcuts for copy and paste on Windows. I feel like a dinosaur every time.

On Linux I just deal with it and curse a lot.

Control-c meant cancel for decades before some idiot decided that it ought to mean copy instead.

As for your pinky, just type the chords correctly and you won’t hurt yourself. This means typing the modifier key(s) with the opposite hand instead of the same hand that is typing the letter. So for control-z you are going to type the “z” with your left hand, so use your right hand to type “control”. That’s why the keyboard has every modifier key on both sides.

> just type the chords correctly

Gee thanks.

I like to have my right hand on a mouse or trackpad, so two handed chords are much less convenient.

Macs manage to make one-handed chords for copy and paste ergonomic, but on a PC it's user error?

> Macs manage to make one-handed chords for copy and paste ergonomic

Cmd-C is not any more ergonomic than Ctrl-C. You are only speaking from position of habit. Pressing modifier with tucked in thumb is not great for it.

If someone is concerned about ergonomics, they should buy ergonomic keyboard. Standard layouts are crap.

Exactly. Either way the keys are too close together for comfortable, and quick, typing. The solution is to move your right hand back to the keyboard and to leave it there. Since selecting text is usually what you do right before you copy it, learn to select the text using keyboard commands.

Ah yes, computing luminary Larry Tesler, what an idiot, working at Xerox PARC. Whoof.

Decades is an exaggeration. It was less than a decade after Digital started using Control-C as a process interrupt in their PDP-10 operating systems (1967) to when Mr Tesler devised his mapping to a copy operation (1974-1976) for Smalltalk-76, and only four years after C was born. CP/M is the much more likely source of widespread usage of control-C as an interrupt, and it was contemporaneous (1974) with Tesler’s mapping.

But they weren’t combined on the same system until decades later, after Windows became nearly ubiquitous and Linux systems started copying things from it.

Reply on news.ycombinator.com