OS X: Option is not ALT! Use Apple (Command) instead

When porting an app from Windows to Mac, a common mistake is to map Alt to Option. This is tempting, since it apparently frees the Command (aka Apple) key to be used for normal Mac commands.

Unfortunately, this is incorrect. Option is used on the Mac to signal non-standard keystrokes and key combos. For instance, to type an accented e (?), you type option-e-e. The first option-e puts a plain accent; the second e turns it into an "eacute" or accented e.

The bottom line is, in IDEA, option-keystrokes are often intercepted at a very low level. This leaves junk around in the text editor, and often erases the very text you were trying to apply a key command to, or leaves some junk around in a file. For instance, try doing control-option-leftarrow to go "back"; when you return to the original buffer you will see some junk.

The solution is for porters to just pretend that the option key doesn't exist. Please go through the OS X keymap and either rename Meta to Alt, or remap all Alt-using key maps to use Meta. The point is -- don't use option!

(Yes, many Mac menus use Command-Option combos. This is acceptable because of the presence of Command, since it signals that it isn't a key input option.)

7 comments

This post is very old, but still true in 2012, and I see that the latest IDEA build is still making this same mistake. Is there a known workaround, perhaps to force the Command key to replace the Option key in all the bound keys?

0

This post is very old, but still true in 2012, and I see that the latest IDEA build is still making this same mistake. Is there a known workaround, perhaps to force the Command key to replace the Option key in all the bound keys?

0

Option _is_ ALT. It even says so on my MacBook Pro keyboard.

The simple fact of the matter is that IntelliJ (and any other app that requires an enormous number of key chords) needs every modifier key it can get. It's impossible to leave Option out of the mix. The downside is that the easy, standard, OS/X extended character entry method doesn't work in IntelliJ. The new Lion method semi-works at the expense of losing repeated keys and getting a spurious additional letter, e.g., holding down the 'e' key gives you an 'e' in the text editor, then the Lion accented character popup appears, you can select the letter and it gets added, giving you something like this - 'eè'. That sucks (and is reported as bug http://youtrack.jetbrains.net/issue/IDEA-78372) but that's the cost of an application that needs every modifier key.

0

Since writing yesterday, I found the defect report IDEA-17392, which captures the issue more directly. Using the "Emacs" keybindings, take the binding for Move Caret to Previous Word. At present, it's bound to Option-B (among others). That seems to be a fine choice, mimicing normal Emacs behavior where Meta-B is bound to backward-word. But in Mac OS, pressing Option-B produces this glyph: ∫. In case that doesn't get captured properly, it's the integral symbol.

IDEA doesn't notice when one presses this Option-B key combination; instead, it only receives the integral symbol character. In the "Keymap" applet in the "Settings" dialog, IDEA shows that it has bindings for Option-B, but a user can never actually issue such a key combination to hit that binding.

I'm not arguing that IDEA should take away the Mac OS behaviour of using the Option key to access additional glyphs. What I wrote is that IDEA's keymaps should neither include by default nor even tolerate such key combinations that it can not even detect. Instead, if this particular binding for Move Caret to Previous Word was with Command-B, everything would work fine. Going through and finding every such binding involving Option and rebinding it with Command seems like a daunting task for each user to muddle through.

0

Note that IntelliJ IDEA's Mac OS-specific keymaps handle this correctly. The Emacs keymap is cross-platform and does not suppress any keybindings that other platforms can handle correctly. Maybe this can be handled by making a customized MacOS specific copy of the Emacs keymap. But it is certainly not a problem that each and every user has to deal with.

0

"Note that IntelliJ IDEA's Mac OS-specific keymaps handle this correctly"

No it doesn't. If you type 'Option-e e' using the 'Mac OS X' keymap you get a pop-up of recent files. If you type 'Option-e e' using the 'Mac OS X 10.5+' keymap it mostly works correctly, but not always. For example, if you have code that looks like this (this happens to be Groovy):

     def list() {
     }

And you click somewhere in the whitespace after the trailing brace (but not immediately after the brace and not after adding spaces after the brace), you'll get something like this:

     def list() {
     }é                        ´


The accent character is left where you clicked and hit 'Option-e', then IntelliJ backs up to the last non-whitespace character and puts the accented character.
0

By "this" I didn't mean accented keys; I meant that the keymaps don't use shortcuts that type special characters in the editor.

0

Please sign in to leave a comment.