As I mentioned in the introduction to these series, different physical keyboards are a source of frustration. This, however, pales in comparison to trying to use Windows as a former macOS user: the different keyboard shortcuts break muscle memory, and this made me feel completely unproductive and… furious every time I made a mistake.

You could say that having difficulty with the Windows shortcuts is simply because I’m not used to the them and that it’s just a matter of time to retrain muscle memory. That’s technically correct, which is the best kind of correct.

Wait, no. The Windows-style shortcuts are objectively bad. An obvious example is the inconsistency around copy and paste across applications. Another obvious example is the difficulty and inconsistency in moving through tabs, which is quite important in today’s world of tabbed applications. Another less-obvious example is the over-reliance on the “right side” of the keyboard (arrow keys and other movement keys), which is not ergonomic to reach.

The great remapping experiment

In order to minimize the transition pain, I was able to port most macOS shortcuts to Windows via AutoHotKey. Getting this to work was incredibly painful but the resulting configuration served me reasonably well for many months.

Unfortunately, using AutoHotKey has been a continuous source of friction:

1. Sometimes, modifier keys get stuck. When this happens, I’m often typing quickly so I end up invoking a chain of unexpected operations. Maddening.

2. Other times, holding a remapped shortcut to repeat it ends up invoking its default functionality. Considering that some of the remapped shortcuts implement Emacs-style cursor movement, this was a serious problem: for example, holding Ctrl-P down to move up in a file would end up opening the print dialog.

3. In some cases, the remapped shortcuts don’t apply because AutoHotKey is running as an unprivileged user and the focused window has administrator-level privileges. Fixable by restarting AutoHotKey as an administrator, but problematic nonetheless.

4. In yet some other cases, AutoHotKey cannot be installed at all, such as on the secure laptop I use to reach production machines or on the production machines themselves. Note that these are on-call response resources, so it is not good to be slowed down by broken muscle memory.

5. The customized shortcuts are not discoverable because they don’t show up in menus or command palettes.

6. The customized shortcuts sometimes conflict with parts of chords (two separate key presses, such as Ctrl+K followed by Ctrl+C), so trying to use the chords that menus and command palettes show is impossible.

All in all, a losing battle. And it’s not AutoHotKey’s fault. I tried the same via the first-party Keyboard Manager that ships with PowerToys and encountered the same set of issues.

So. Now that I’ve taken the final step in abandoning macOS—I removed the OS from my Mac Pro just a week ago—I’ve decided that it’s finally time to stop being stubborn and retrain myself to the PC way of doing things. It is not easy. I still don’t like the inconsistencies across apps.

And I’ll probably have to do a few customizations to remain productive. For example, to make this process bearable, I’ve installed Vim emulation in VSCode for the first time ever. Yes, this will prevent me from completely adjusting to the native shortcuts. But… using special bindings in an editor or IDE is a pretty common thing to do, and configuring the editor itself is not the same as trying to use a system-wide key remapper, so… this is fair game, right?

In the end, I know this retraining process will be beneficial for me. Using AutoHotKey to remap most of the keyboard is a sure way to be unable to user other machines, so getting rid of that will make me more productive overall. Plus… getting used to the typical PC shortcuts means that using FreeBSD or Linux on the desktop will become a realistic possibility once again.

Copy and paste woes

Having accepted that I have to learn the native shortcuts, let’s go back to talking about copy and paste inconsistencies. This might sound like a minor issue if you have never used macOS, but once you experience homogeneous shortcuts across the system—Cmd+C to copy, Cmd+V to paste—it’s hard to imagine how such an obvious feature can be so broken in other systems. Windows is not alone here: the same problems plague every Linux desktop I have used.

The major offender are console applications. If you don’t use the terminal, copy and paste is probably fairly homogeneous to you. But if you do, you know that Ctrl+C is supposed to interrupt the currently running program and Ctrl+V is a useful shortcut in Vim and Emacs. Which means that terminal emulators cannot use these for handling clipboard commands. Terminal emulators then have to use other shortcuts, such as Shift+Ctrl+C for copying and Shift+Ctrl+V for pasting.

Windows Terminal tries to “fix” these inconsistencies by adding additional modal shortcuts in its default configuration (shown below). You can imagine how this can go wrong:

[
    // Copy and paste are bound to Ctrl+Shift+C and Ctrl+Shift+V in your
    // defaults.json.
    // These two lines additionally bind them to Ctrl+C and Ctrl+V.
    // To learn more about selection, visit https://aka.ms/terminal-selection
    { "command": {"action": "copy", "singleLine": false }, "keys": "ctrl+c" },
    { "command": "paste", "keys": "ctrl+v" }
]

Speaking of keyboard shortcuts provides the right segue to the clipboard behavior. I don’t know who had the brilliant idea of making copy and paste preserve the formatting of the source text. This is almost never ever what you want. Have you seen how some email messages are a hodgepodge of different text styles? Have you seen how, sometimes, the font changes half-way through a paragraph because someone had to copy a person’s name with non-ASCII character in it? This is why.

Now, mind you: this “awesome” idea spills to macOS too. The key difference is that, on macOS, Shift+Cmd+V exists to paste without formatting, universally. I grew so accustomed to this shortcut that I almost always used it without giving this problem a second thought.

On Windows, well, it’s a shit show. Ctrl+V keeps formatting and… that’s about it? There is no consistent shortcut to paste without formatting. The Office apps want you to press Ctrl+V, then press Ctrl, and then press t. In other apps, who knows. And there is Win+V now as well, but that’s just extra clicks. I just cannot believe how many stories I’ve read online from people praising Notepad simply because it’s their go-to tool for stripping formatting from text.

Sad state of affairs

As you can tell, this is a topic that makes me quite sad. I felt very productive on macOS with the keyboard alone: the dedicated Cmd key for shortcuts that don’t overlap with Ctrl is truly useful; the existence of Emacs-style cursor movement shortcuts throughout the system was a big plus; and the fact that most shortcuts don’t require reaching to the far right side of the keyboard (non-existent on laptops!) is efficient.

I guess I’m extra sad because Microsoft had the unique chance to fix all of this back in 1995 when they introduced the new Win and Menu keys to the PC keyboard. That’s not what happened though, and I still don’t understand why these keys are so under-utilized.

Anyhow. Embracing the change will be beneficial for me in the hopefully not-too-distant future. Too much customization is detrimental to productivity, especially when dealing with multiple computers, so it’s good to not fiddle with the defaults too much. That’s a whole approach to using software that maybe I should talk about some day, because I was the kind of person that customized every little detail several years back!

Enough ranting. This is likely the most negative post in this whole series reviewing modern Windows but I had to get it out of the way. Stay tuned for tomorrow’s episode on the GUI input methods!