As an emacs user, I'm pretty happy to mostly not have this problem.
All of the command-line apps I depend on either use GNU readline (which has flawless emacs style editing) or can be hacked to do so with the rlwrap utility. Furthermore since many of the NeXTSTEP hackers were also emacs users, OSX text input widgets inherited very solid (although the kill ring is lacking) keyboard binding support which makes it possible for me to comfortably emacs-style edit in native OSX apps.
Sometimes though stupid rich text input boxes used by wikis can annoyingly rebind emacs keys, and then I fly into a fit of rage like the author described. Luckily there is 'It's all text!' under Firefox or 'Edit with Emacs' on Chrome that lets you use an external editor to edit the contents of any web text widget, which I use to do all my wiki editing.
Readline has vi mode, and it's amazing. I use vi mode in zsh, bash, ruby, python, mysql, etc. and I can't live without it any more.
I still have fit-of-rage moments when I try to use things that either (a) try to roll their own line editing or (b) use some inferior readline clone.
rlwrap is nice, but typically the shells I'm using have other functionality that I miss too much (tab-completion) if I use it. For instance, I've given up using rlwrap with the Scala repl for this reason.
I hear that. At some point Ubuntu screwed up and linked the MySQL client with libedit instead of readline, which has caused me much wailing and gnashing of teeth. Don't get me started on all the ways Ubuntu / Debian has fucked up the packaging of MySQL.
Yes it's a nice benefit for emacs users that readline offers good emacs-style editing. Although, enough command line tools support vim-style editing too that the level of benefit is not much.
However, it seems like it's a common problem not to be able to specify your own behavior for GUI controls at a system level
Readline also has a vi mode, which I've heard is pretty good.
I agree that a good OS should allow you to choose your editing keys (either vim or emacs style) and not allow applications to step on them. Unfortunately that's a feature that most users probably wouldn't care about.
On the other hand, the feature wouldn't hurt them; if a default user-friendly interface personality is provided with the existing behavior, they don't even have to know that the the system is swappable.
If my hands weren't so full and I had any special level of expertise with GUI development, this is an itch I would find worth scratching - I don't imagine this could occur anywhere but linux and bsd, though.
I started to worry about this as I got older, so a few years ago I got a Kinesis Advantage keyboard at work and home with the control and meta keys mapped to the left thumb buttons backspace/delete. I was able to break the left-pinky control habit by mapping my CAPSLOCK key to a noop.
The Kinesis took a few weeks to get used to, I sped up my progress by competing in typing races on typeracer.com until my speed got back up, and eventually surpassed my speed on a conventional keyboard. The square, curly, and angle bracket keys took a lot longer to get used to, and it was months before I got comfortable with them.
All of the command-line apps I depend on either use GNU readline (which has flawless emacs style editing) or can be hacked to do so with the rlwrap utility. Furthermore since many of the NeXTSTEP hackers were also emacs users, OSX text input widgets inherited very solid (although the kill ring is lacking) keyboard binding support which makes it possible for me to comfortably emacs-style edit in native OSX apps.
Sometimes though stupid rich text input boxes used by wikis can annoyingly rebind emacs keys, and then I fly into a fit of rage like the author described. Luckily there is 'It's all text!' under Firefox or 'Edit with Emacs' on Chrome that lets you use an external editor to edit the contents of any web text widget, which I use to do all my wiki editing.