One of my favorite Mac OS features is support for basic Emacs keystrokes for editing and navigation. If you're unfamiliar with this feature, start editing some text in a Cocoa app like TextEdit or Mail, and try ^A, ^B, ^D, ^E, ^F, ^K, and ^T, to name just a few. This functionality is built into standard Cocoa text controls like NSTextField and NSTextView.
Occasionally I come across a web site that intercepts keystrokes that would normally be Emacs keystrokes. For example, a site might implement a rich text editor and use ^B to mean "bold", which is a familiar shortcut for Windows users, but means "move one character backward" to Emacs users. I wish these web sites would detect the platform they're running on and use familiar Mac shortcuts — in this case, Command-B — which would have the double benefit of being naturally discoverable for Mac users and not overloading an Emacs keystroke.
Native apps can "break Emacs" too. I just reported a bug in Sublime Text where ^K (kill to end-of-paragraph) doesn't work in the text field in its Save dialog. I suspect this is because, for some reason, Sublime Text explicitly maps ^K to an item in the Edit menu instead of falling back on the default Cocoa behavior.
In July I filed Radar 11964801 on iTunes because ^D (forward delete) doesn't work in the Search field — a bizarre edge case if I ever saw one. ^D isn't mapped to any menu item in iTunes, nor is it documented as a keyboard shortcut for either Mac or Windows. I really wonder what causes this bug. My Radar was marked as a duplicate of 11306235, so there's at least one other picky nerd out there.
Here's how picky I am. Suppose there was a magical "Mac OS, PC Edition" that could run on any cheap PC hardware. Suppose for some perverse reason the "PC Edition" lacked the Emacs feature but was identical to Mac OS in all other respects. I wouldn't even consider it. I'd still pay more for Apple hardware, although I would certainly consider recommending the "PC Edition" for less nerdy friends and relatives.
And so, while I realize these Emacs breakages are trivial-beyond-trivial in the grand scheme of things, I'd still like to register this tiny plea to developers targeting the Mac: please don't break Emacs.
Pingback: Michael Tsai - Blog - Don’t Break Emacs Shortcuts
Nice catches. Emacs key bindings are very important part of the Mac experience to me. I'm far less productive when they're broken.
Andy,
Do you still develop code with Emacs as your primary editor? I do, and I have to say it mostly makes me feel like a dinosaur around these kids. However, I have yet to see one of them do something with Eclipse that makes it compelling to switch… Never really had any reason to open Xcode for any length of time, my career hasn't taken me there.
-John
Oh, I've never used Emacs itself as a primary editor. I only learned enough of the key bindings to do basic cursor movement and editing. The key bindings were supported system-wide way back in NeXTSTEP (speaking of dinosaurs) and this feature was inherited by Mac OS X. So as I type this now in Safari, I use ^A, ^E, ^B, ^F, ^P, ^N instead of arrow keys to move around the text. Likewise when I'm editing text anywhere — typing a URL, composing email, renaming a file, editing code — the keystrokes are supported. A notable exception is the MS Office apps, but even there I think I read about some way to make them use Emacs keys.
Back when Eclipse was my IDE it would have driven me nuts if it didn't have a way to support basic Emacs key bindings.
Nice to hear from you, John!
Here's a few more:
You can also add some of the meta and mark keybindings by creating a DefaultKeyBinding.dict like http://www.hcs.harvard.edu/~jrus/site/KeyBindings/Emacs%20Opt%20Bindings.dict. But it won't work at all in Xcode 4.
Lauri — quite a list! I haven't tested them all, but at least some seem to have been fixed.
Nice to know I'm not the only one who notices.