> I'm guessing there's no easy way to replace the definition of the deleteToEndOfParagraph: action with something else...
with DYLD_INSERT_LIBRARIES and method_exchangeImplementations (and maybe launchd to apply that DYLD_INSERT_LIBRARIES to everything?).
What you have to do is:
Implement a category message that does what you want (my_deleteToEndOfParagraph:).
Write a function that uses method_exchangeImplementations to replace deleteToEndOfParagraph: with my_deleteToEndOfParagraph:. deleteToEndOfParagraph: probably depends on class (NSTextView, NSTextField, WebView, etc.)
Create a shared library that uses your function as an initialization routine.
Inject that shared library into every app on the system.
As you can see this is very easy. Har har har.
Also, when replacing methods, it's better to do it like this, by storing the actual function pointer to the implementation: http://pastie.org/private/nbaaog7hptyzsytahpc5a — it makes "stacked" overrides (imagine an app tried to hook the same thing as well, you don't want that to cause issues) safer than renaming.
As if the normal use case is that of a user wanting to change some text editing bindings back to Emacs-like behavior...
"Two different libraries to implement text-field editing -- because, you know, that's somewhere you might want to diverge and innovate."
For example, theres' case of stealing text from copy/paste buffer http://news.ycombinator.com/item?id=3314004
It is just as dangerous "in here" too...
I respectfully submit that those who expect their OS to act like emacs as a matter of design rather than historical happenstance have plenty of other options out there. But I also understand that it's not fun to have the rug pulled out from under you in this way.
I don't use emacs, but i did learn ctrl-k, ctrl-y and some others.
This seems to imply you shouldn't have keyboard shortcuts at all. After all, the principle of least astonishment says that if you hit a key combination you didn't intend, nothing you didn't intend to happen should happen.
OS X should be agnostic about the software running on it. If you fix it for Emacs, then it should also be fixed for vi users and nano users, etc. some of which are mutually exclusive.
This is not because Apple particularly sponsors Emacs, but because historically, Mac key bindings and Emacs key bindings were the same for those functions. So it's the same (roughly) as finding that Command-A, Command-C and Command-V no longer work the way they used to.
I'm unsure if it works in 10.7 though.
As ever, feedback is welcome.
I think he basically wants the kill buffer to be wiped out when you move between kills. His demo shows that in OSX text fields this is no longer the case, and at least on my machine running 10.6.something this is true. Emacs of course still behaves the way he wants.
Oh, the fur flew. Post-facto, managers piled on and tried to make the feature more Mac-like. It was fine as it stood. It was amusing to watch.
Also, developers loved it.
Also, Apple is one strange company. A friend who worked there as a contractor told me that there were two Perl teams there, working in different buildings. He organized a lunch so that the two teams could meet each other. After someone higher up found out, that was the end of his contract. Apparently there is so much secrecy that even teams working on bullshit HR apps (or the equivalent) can't even have lunch together.
Apple is a cult. Follow the rules or you go to hell.
Once it was in there, they didn't roll it back for some reason -- probably because a lot of folks secretly liked the feature and killing it would have been politically difficult. So the User Interface people (why you have these on a command shell is beyond me) were given a chance to pee in the feature for a bit, until they liked the flavor, and it shipped. My cow-orker got into some hot water.