Alt, AltGr, and Mac/PC mode

[ErikMH]

I can’t speak much to Windows/Linux correspondences with the Mac, but I can tell you about the Mac in isolation (I left DOS for Mac OS in 1985).

The command key ⌘ is consistently used in at least 95% of applications and in the operating system for “command-key equivalents” (i.e., menu shortcuts). Every Mac user, from developers to data-entry clerks will at a minimum use ⌘C (copy), ⌘V (paste), ⌘X (cut), ⌘Z (undo), ⌘F (find), ⌘S (save), ⌘P (print) — all of which have been baked in to the operating system since 1984.

Lots of other commands are more-or-less standard, with the better apps making a good effort to place less-common variations on the same keys with more modifiers (⇧⌘V to paste with matching the surrounding style, for example). Traditionally, the additional modifiers used with the command key would only be the shift key ⇧, the option key ⌥, or a combination of the two. More recently, some apps will now add control ˆ to the mix — but those are comparatively rare.

This means that Mac users who prefer keyboarding to mousing (and my guess is that the vast majority of Mac users interested in the Model 01 will fall into this camp) need fairly easily to be able to chord at least ⇧⌘, ⌥⌘, and (somewhat less often) ⌥⇧⌘. Personally, I use control a lot as well (for Keyboard Maestro macros), but that’s far less common.

While typing text, shift is obviously crucial; but so too is option, as all common European characters can be easily obtained via combinations of option and letter keys (on the US QWERTY keyboard). For example, a “ç” is simply ⌥C; a vowel with an acute accent (e.g., “é”) is formed with ⌥E as a dead key chord preceding the vowel you want to put the accent over.

So it would seem that easy access, speed, and ergonomics are important for the shift and option keys, and that easy access and ergonomics likewise are important for the command key.

The control key is far less common, as I observed above — but I should note that users coming from programming backgrounds — as well as a few others, of course — use it for some textual navigation, and it’s also now used in the OS for things like switching display spaces, bringing up contextual menus (many users don’t know that a “right click” can be generated by tapping two fingers on a touchpad, for example).

In the Mac world, the term “alt” was never used in the U.S. As more users have migrated in from Windows, it’s now beginning to be used interchangeably with “option,” although U.S. keyboards still have “option” printed on the key. In other parts of the world, I believe the key is called “alt.”

I have absolutely no idea what the terms “altgr” or “right alt” mean; if they refer to a distinction between the left and right option (alt) keys, then as far as I know this distinction does not exist on the Mac, at least at the operating system and application level.

[andrewg (Andrew Gallagher)]

@algernon

Mhm. I see. I’ll swap Ctrl/Command then. For the commandline, a small agent on the host that can talk to the keyboard, would be able to tell the keyboard when to switch back and forth between swapping and not swapping…

How many different command lines do you plan on supporting with this tool though? I have Terminal and iTerm2 installed on mine, and macOS also has a physical console.

And then there’s X…

[algernon (Gergely Nagy)]

@andrewg

How many different command lines do you plan on supporting with this tool though? I have Terminal and iTerm2 installed on mine, and macOS also has a physical console.

And then there’s X…

Argh, yeah. Ok. It’s easy to support any number of apps (just have a list of those that require PC codes as opposed to Mac ones, and make that list easy to extend/change in a config file). But adding X and console to the mix is just cruel.

I’ll just scrap the plugin instead, as changing the keymap itself sounds like a much smaller task. Even for an end-user, having a Mac layer and a PC layer would likely be easier than fighting a tool that tries to do something automatic, judging by the explanations above.

Thanks to you and @ErikMH for the in-depth explanation!

[andrewg (Andrew Gallagher)]

@ErikMH

I have absolutely no idea what the terms “altgr” or “right alt” mean; if they refer to a distinction between the left and right option (alt) keys, then as far as I know this distinction does not exist on the Mac, at least at the operating system and application level.

That is correct - altgr is how non-US PC keymaps achieve Mac’s standard Option key behaviour. Although there may seem to be no difference between left and right handed modifier keys, they are distinct at a logical level - it’s just that most keymaps assign the same behaviour to both sides so that they can be used comfortably with either hand. There are a few exceptions such as AltGr and some hotkey-driven utilities that like to camp on unusual combinations such as leftshift+rightshift.

[merlin (Michael Richters)]

Recent Apple keyboards have the words “option” and “alt” printed on the same keys. I’m pretty sure the scan code is the same as Alt on PC keyboards.

Control is located in the same position as on PC keyboards.

Command is located between the spacebar and Option (in the same position as Alt on typical PC keyboards, but I believe it sends the same scan code as the Windows key on PC keyboards.

I’ve got a Logitech bluetooth keyboard in front of me that has separate Mac and PC modes, and it has the keys adjacent to the spacebar marked as “alt” for PC and “command” for Mac.

Personally, I’m planning to set things up with a Command key on the left, and Alt/Option key on the right, and use Palm + Command to send LAlt/LOption, and Palm + Alt to send RCommand. This gives me all eight usual modifiers, and a nearly-symmetric keyboard.

My draft layout is on KLE.

[andrewg (Andrew Gallagher)]

@merlin

Personally, I’m planning to set things up with a Command key on the left, and Alt/Option key on the right, and use Palm + Command to send LAlt/LOption, andPalm+Altto sendRCommand. This gives me all eight usual modifiers, and a nearly-symmetric keyboard.

If you’re using the palm fn key to modify your modifiers, then you can’t use it for an embedded fn-layer. Is that what you intend?

[merlin (Michael Richters)]

@andrewg

If you’re using the palm fn key to modify your modifiers, then you can’t use it for an embedded fn-layer.

Why not? “Fn+Command” is “Alt” in my plan. Is there some reason that’s impossible?

[andrewg (Andrew Gallagher)]

@merlin

If you’re using the palm fn key to modify your modifiers, then you can’t use it for an embedded fn-layer.

Why not? “Fn+Command” is “Alt” in my plan. Is there some reason that’s impossible?

Let’s take the example of arrow keys. To get an arrow key, you hit fn+hjkl. So to get command-arrowkey you hit fn+command+hjkl. But if fn+command is now alt…?

[merlin (Michael Richters)]

@algernon

I’ll just scrap the plugin instead, as changing the keymap itself sounds like a much smaller task. Even for an end-user, having a Mac layer and a PC layer would likely be easier than fighting a tool that tries to do something automatic, judging by the explanations above.

I want a mode switch that’s independent of layers and doesn’t require anything more than pressing some key combination, but all I need it for is the most common commands that are different. Cut, copy, paste, and undo are infuriating when switching back and forth, as I do, because they use Command on Mac, but Control on everything else. Application and window switching are the other one (Command on Mac, but Alt on everything else).

My biggest problem is that Emacs and XQuartz apps (i.e. Inkscape) continue to use Control and Alt(Option), but not Command.

[merlin (Michael Richters)]

@andrewg

Let’s take the example of arrow keys. To get an arrow key, you hit fn+hjkl. So to get command-arrowkey you hit fn+command+hjkl. But if fn+command is now alt…?

Oh, thanks! This is so much easier to do when actually testing…

[algernon (Gergely Nagy)]

@merlin

I want a mode switch that’s independent of layers and doesn’t require anything more than pressing some key combination, but all I need it for is the most common commands that are different. Cut, copy, paste, and undo are infuriating when switching back and forth, as I do, because they use Command on Mac, but Control on everything else. Application and window switching are the other one (Command on Mac, but Alt on everything else).

My biggest problem is that Emacs and XQuartz apps (i.e. Inkscape) continue to use Control and Alt(Option), but not Command.

There are building blocks that help you achieve this, you just have to lego the pieces together (I’ll happily help with that, these make very good examples for documentation and HOWTOs), instead of having a ready-made, generic plugin that Just Works™ (this last bit appears to be the… impossible task in this case).

[merlin (Michael Richters)]

@andrewg

Let’s take the example of arrow keys. To get an arrow key, you hit fn+hjkl. So to get command-arrowkey you hit fn+command+hjkl. But if fn+command is now alt…?

Now that I think about it, that’s not the real problem. I could still get command+arrow by using Fn+alt+arrow. The problem is that it doesn’t actually get me the other modifiers with keys that are re-mapped on that layer…unless I do something more complicated, like using left palm + right alt to get right command as a one-shot or sticky modifier, but using right palm + right alt alone.