5 ms·

jwz: Apple recently broke Ctrl-Y

120 points by michaelty 15y ago

Uhhrrr 15y ago
I'm always agog when an organization changes something beloved like key bindings. Qui bono? Someone who uses them is in the same boat as everyone else, muscle memory-wise. And someone who doesn't shouldn't care. And in either case, there should be enough people with facial hair (or female equivalent) who will block it because toying with user expectations is bad.
- telemachos 15y ago
  This is a tangent, but you want 'cui bono'[1]. 'Qui' is the nominative; the phrase is a double dative. (Not trying to be a jerk, but I figured you might want to know.) [1]: http://en.wikipedia.org/wiki/Cui_bono http://en.wikipedia.org/wiki/Cui_bono
  - docgnome 15y ago
    My thanks for this tangential line of thought. I didn't know what was being referred to.
  - Uhhrrr 15y ago
    Thanks!
- funkah 15y ago
  You can easily flip the question around, though. Who benefits if OS X keeps this key binding? A few people who still use some arcane, 30-year-old text editor. And the rest of us are stuck wondering what the heck just happened when we accidentally press one of these shortcuts. 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.
  - xenophanes 15y ago
    Everyone benefits by the possibility of learning useful shortcuts that work in stuff like safari text fields -- no matter the bindings, and no matter how old -- as long as Apple isn't adding more modern ones. I don't use emacs, but i did learn ctrl-k, ctrl-y and some others.
    - lloeki 15y ago
      Not using emacs here but regular user of bash, zsh and various readline-based tools (python, irb, mysql...), ^A ^E ^K ^Y are extremely useful, everyday, so it's a boon to have them working in every text box in the system.
  - derleth 15y ago
    > And the rest of us are stuck wondering what the heck just happened when we accidentally press one of these shortcuts. 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.
natesm 15y ago
HOKAY. So you can totally do this: > 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.
- Xuzz 15y ago
  It's somewhat difficult to do DYLD_INSERT_LIBRARIES right on OSX; it tends to subtly break various system components even if your binary doesn't do anything. However, SIMBL (http://www.culater.net/software/SIMBL/SIMBL.php http://www.culater.net/software/SIMBL/SIMBL.php) usually works fine. (On the (jailbroken) iPhone, you'd want MobileSubstrate (http://iphonedevwiki.net/index.php/MobileSubstrate http://iphonedevwiki.net/index.php/MobileSubstrate), which does use DLYD_INSERT_LIBRARIES, where it causes few to no issues.) 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 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.
- krakensden 15y ago
  And people complain about Linux wasting your time.
  - dextorious 15y ago
    Are you for real? As if the normal use case is that of a user wanting to change some text editing bindings back to Emacs-like behavior...
- thwarted 15y ago
mdanger 15y ago
As a non-emacs user: can someone explain what jwz is talking about here?
- spacemanaki 15y ago
  Did you follow his little demo? Let me see if I can explain it. "Killing" in Emacs-jargon is similar to cutting (ctrl/cmd X). Holding control and pressing "k" (C-k) deletes the text starting at the cursor (point) up until the end of the line, and puts that text in a buffer. It can be pasted (yanked) with C-y. In Emacs, killing multiple times without any other movement between kills appends each bit of text to the buffer. If you move between kills the buffer is wiped out, and subsequent kills put the killed text into a clean buffer. 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.
  - dylangs1030 15y ago
    That was actually a great explanation - to clarify a bit, yes, jwz doesn't have any issue with Emacs. But Mac used to use the same key bindings typical of Emacs, so jwz is miffed because for people comfortable in that environment, it's a pain to not be able to use the same shortcut for what amounts to copy, paste and cut.
phren0logy 15y ago
File a bug. This seems like the kind of thing that Apple would actually fix. https://bugreport.apple.com/ https://bugreport.apple.com/
- drivingmenuts 15y ago
  Or not. 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.
  - macrael 15y ago
    The point is that all generic text fields on OSX have supported Emacs keybindings since forever, not vi or nano keybindings.
    - throw_away 15y ago
      though, this thread just makes me want vi bindings in os x text areas. I would settle for shell bindings that can change the cursor shape.
  - dylangs1030 15y ago
    A company can fix a problem without sponsoring a product associated with the problem, just like a company can release a product for a competing platform.
    - deleted 15y ago
      [deleted]
      - omaranto 15y ago
        He doesn't want the key binding to be Emacs-like he wants to go back to being the way it was before this random change, the way he had already gotten used to. That is, he wants it to be Apple-like again. (It happens that the old Apple way and the Emacs way coincide, which is probably what confused you.)
xenophanes 15y ago
you can change the keybindings to do multiple things, not just pick a single preset command like deleteToEndOfParagraph. not sure how much help that is though, since what he wants is kind of adding "truncate buffer" (or at least "setLastCommandFlag") to ALL other commands, rather than actually changing ctrl-k itself. this is not a problem with the deleteToEndOfParagraph implementation though, and i don't see how hacking that could help, since he wants something to happen after hitting arrows keys, typing, etc...
vault_ 15y ago
You can set per-user shortcuts for this. http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html I'm unsure if it works in 10.7 though.
- jacobolus 15y ago
  It always brings a smile to see my 2006 page linked. :) As ever, feedback is welcome.
  - afiler 15y ago
    I've used your documentation before, and it's amazingly useful. It's let me solve keyboard mapping issues in the least hacky way possible, especially when combined with KeyRemap4MacBook.
js2 15y ago
Hmm, I can reproduce this in Safari, but not in TextEdit, nor TextMate, under 10.7.2.
- jacobolus 15y ago
  TextEdit uses the default cocoa text widget. Both TextMate and Safari have reimplemented it. TextMate’s text widget is substantially more sophisticated, and Safari’s is mostly compatible except for a few annoying edge cases (it’s been a few years since I investigated; maybe some have been fixed).
- kickingvegas 15y ago
  As mentioned in the link's comment thread, ^Y is broken for Webkit. I just tried this in Mail.app and it worked fine.
  - bdash 15y ago
    Amusingly enough, Mail’s compose window uses WebKit for the content area. According to http://webkit.org/b/73888 http://webkit.org/b/73888 the issue is specific to the WebKit2 layer that is currently used only by Safari.
brudgers 15y ago
While I can understand the issue the change creates for the author, a nexus between the emacs interface and Apple's overall user experience philosophy would appear to be somewhat hard to find.
- kabdib 15y ago
  I nearly got a guy on the MPW Shell team fired -- I was egging him on to add keyboard macros to MPW (the Macintosh Programmer's Workshop), and he eventually did. They were powerful enough to emulate at least a top-level mostly Emacs environment. 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.
  - WalterGR 15y ago
    Why would that be (nearly) a firing offense?
    - jrockway 15y ago
      Because it makes the story more interesting. 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.
    - kabdib 15y ago
      He checked in the code without permission. 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.
mhartl 15y ago
I use ^K all the time, but somehow I didn't remember ^Y from my dalliance with Emacs a decade ago. And now that I know I want it, I can't have it. Crap.
dylangs1030 15y ago
To clarify this a bit for non-Emacs users (as I saw a comment), the tl;dr version is that jwz wants Mac to maintain the Emacs key bindings that essentially amount to a specialized set of copy, cut and paste functions in text editing. 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.
- Someone 15y ago
  Clarification of this for those interested in history: The original Mac did not have control keys; I guess NextStep had some Emacs bindings. When Mac OS and NextStep gave birth to Mac OS X, it was possible to keep both sets, as there could not be clashes. I am not sure those Emacs bindings 'officially' exist, though (the human interface guidelines mention the use of the control key for accessibility, but not for text editing)
sambeau 15y ago
Just to be clear, these are standard Shell keybindings that Emacs also uses—not 'Emacs keybindings'.
- drv 15y ago
  Emacs had them first; shells copied them.
  - deleted 15y ago
    [deleted]
  - sambeau 15y ago
    Well that's me shattered.
- cstejerean 15y ago
  I believe they are actually emacs bindings. These bindings originates in emacs and were then used by readline. Software that uses readline then acquires these bindings, including bash, etc. So I wouldn't say that these are standard shell bindings that happen to be used by emacs, since they originated in emacs and shells happen to use them.
  - sambeau 15y ago
    Thanks. I've been living a lie for years. :)
feralchimp 15y ago
Great comments thread on that post, including this gem after WebKit is fingered as the wrongdoer: "Two different libraries to implement text-field editing -- because, you know, that's somewhere you might want to diverge and innovate." LOL.
- jvdh 15y ago
  Makes a whole lot of sense to me. Text input in a browser should be handled a lot more carefully than text input to "regular" system applications.
  - waitwhat 15y ago
    Why? What is so special about the browser? (or is my sarcasm detector failing again?)
    - JonnieCache 15y ago
      Browsers get used as word processors, chatrooms etc.
    - dexen 15y ago
      Unlike most desktop apps, browsers interface user directly with the internet, and it is dangerous out there. For example, theres' case of stealing text from copy/paste buffer http://news.ycombinator.com/item?id=3314004 http://news.ycombinator.com/item?id=3314004
      - dfxm12 15y ago
        More and more desktop apps are interfacing the users with the Internet though, especially when you extrapolate Apple's model with their app store. It is just as dangerous "in here" too...
prawn 15y ago
"Update: Holy shit! I am told that this bug was fixed FIVE HOURS after I posted this -- Webkit bug 73888 [1] and the patch [2]. Thanks, Alexey!" 1. https://bugs.webkit.org/show_bug.cgi?id=73888 2. https://bug-73888-attachments.webkit.org/attachment.cgi?id=117988

120 points by michaelty 15y ago

I'm always agog when an organization changes something beloved like key bindings. Qui bono? Someone who uses them is in the same boat as everyone else, muscle memory-wise. And someone who doesn't shouldn't care. And in either case, there should be enough people with facial hair (or female equivalent) who will block it because toying with user expectations is bad.

telemachos 15y ago
This is a tangent, but you want 'cui bono'[1]. 'Qui' is the nominative; the phrase is a double dative. (Not trying to be a jerk, but I figured you might want to know.) [1]: http://en.wikipedia.org/wiki/Cui_bono http://en.wikipedia.org/wiki/Cui_bono
- docgnome 15y ago
  My thanks for this tangential line of thought. I didn't know what was being referred to.
- Uhhrrr 15y ago
  Thanks!
funkah 15y ago
You can easily flip the question around, though. Who benefits if OS X keeps this key binding? A few people who still use some arcane, 30-year-old text editor. And the rest of us are stuck wondering what the heck just happened when we accidentally press one of these shortcuts. 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.
- xenophanes 15y ago
  Everyone benefits by the possibility of learning useful shortcuts that work in stuff like safari text fields -- no matter the bindings, and no matter how old -- as long as Apple isn't adding more modern ones. I don't use emacs, but i did learn ctrl-k, ctrl-y and some others.
  - lloeki 15y ago
    Not using emacs here but regular user of bash, zsh and various readline-based tools (python, irb, mysql...), ^A ^E ^K ^Y are extremely useful, everyday, so it's a boon to have them working in every text box in the system.
- derleth 15y ago
  > And the rest of us are stuck wondering what the heck just happened when we accidentally press one of these shortcuts. 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.

natesm 15y ago

HOKAY. So you can totally do this: > 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.

Xuzz 15y ago
It's somewhat difficult to do DYLD_INSERT_LIBRARIES right on OSX; it tends to subtly break various system components even if your binary doesn't do anything. However, SIMBL (http://www.culater.net/software/SIMBL/SIMBL.php http://www.culater.net/software/SIMBL/SIMBL.php) usually works fine. (On the (jailbroken) iPhone, you'd want MobileSubstrate (http://iphonedevwiki.net/index.php/MobileSubstrate http://iphonedevwiki.net/index.php/MobileSubstrate), which does use DLYD_INSERT_LIBRARIES, where it causes few to no issues.) 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 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.
krakensden 15y ago
And people complain about Linux wasting your time.
- dextorious 15y ago
  Are you for real? As if the normal use case is that of a user wanting to change some text editing bindings back to Emacs-like behavior...
thwarted 15y ago

mdanger 15y ago

As a non-emacs user: can someone explain what jwz is talking about here?

spacemanaki 15y ago
Did you follow his little demo? Let me see if I can explain it. "Killing" in Emacs-jargon is similar to cutting (ctrl/cmd X). Holding control and pressing "k" (C-k) deletes the text starting at the cursor (point) up until the end of the line, and puts that text in a buffer. It can be pasted (yanked) with C-y. In Emacs, killing multiple times without any other movement between kills appends each bit of text to the buffer. If you move between kills the buffer is wiped out, and subsequent kills put the killed text into a clean buffer. 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.
- dylangs1030 15y ago
  That was actually a great explanation - to clarify a bit, yes, jwz doesn't have any issue with Emacs. But Mac used to use the same key bindings typical of Emacs, so jwz is miffed because for people comfortable in that environment, it's a pain to not be able to use the same shortcut for what amounts to copy, paste and cut.

phren0logy 15y ago

File a bug. This seems like the kind of thing that Apple would actually fix. https://bugreport.apple.com/ https://bugreport.apple.com/

drivingmenuts 15y ago
Or not. 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.
- macrael 15y ago
  The point is that all generic text fields on OSX have supported Emacs keybindings since forever, not vi or nano keybindings.
  - throw_away 15y ago
    though, this thread just makes me want vi bindings in os x text areas. I would settle for shell bindings that can change the cursor shape.
- dylangs1030 15y ago
  A company can fix a problem without sponsoring a product associated with the problem, just like a company can release a product for a competing platform.
  - deleted 15y ago
    [deleted]
    - omaranto 15y ago
      He doesn't want the key binding to be Emacs-like he wants to go back to being the way it was before this random change, the way he had already gotten used to. That is, he wants it to be Apple-like again. (It happens that the old Apple way and the Emacs way coincide, which is probably what confused you.)

xenophanes 15y ago

you can change the keybindings to do multiple things, not just pick a single preset command like deleteToEndOfParagraph. not sure how much help that is though, since what he wants is kind of adding "truncate buffer" (or at least "setLastCommandFlag") to ALL other commands, rather than actually changing ctrl-k itself. this is not a problem with the deleteToEndOfParagraph implementation though, and i don't see how hacking that could help, since he wants something to happen after hitting arrows keys, typing, etc...

vault_ 15y ago

You can set per-user shortcuts for this. http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html I'm unsure if it works in 10.7 though.

jacobolus 15y ago
It always brings a smile to see my 2006 page linked. :) As ever, feedback is welcome.
- afiler 15y ago
  I've used your documentation before, and it's amazingly useful. It's let me solve keyboard mapping issues in the least hacky way possible, especially when combined with KeyRemap4MacBook.

js2 15y ago

Hmm, I can reproduce this in Safari, but not in TextEdit, nor TextMate, under 10.7.2.

jacobolus 15y ago
TextEdit uses the default cocoa text widget. Both TextMate and Safari have reimplemented it. TextMate’s text widget is substantially more sophisticated, and Safari’s is mostly compatible except for a few annoying edge cases (it’s been a few years since I investigated; maybe some have been fixed).
kickingvegas 15y ago
As mentioned in the link's comment thread, ^Y is broken for Webkit. I just tried this in Mail.app and it worked fine.
- bdash 15y ago
  Amusingly enough, Mail’s compose window uses WebKit for the content area. According to http://webkit.org/b/73888 http://webkit.org/b/73888 the issue is specific to the WebKit2 layer that is currently used only by Safari.

brudgers 15y ago

While I can understand the issue the change creates for the author, a nexus between the emacs interface and Apple's overall user experience philosophy would appear to be somewhat hard to find.

kabdib 15y ago
I nearly got a guy on the MPW Shell team fired -- I was egging him on to add keyboard macros to MPW (the Macintosh Programmer's Workshop), and he eventually did. They were powerful enough to emulate at least a top-level mostly Emacs environment. 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.
- WalterGR 15y ago
  Why would that be (nearly) a firing offense?
  - jrockway 15y ago
    Because it makes the story more interesting. 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.
  - kabdib 15y ago
    He checked in the code without permission. 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.

mhartl 15y ago

I use ^K all the time, but somehow I didn't remember ^Y from my dalliance with Emacs a decade ago. And now that I know I want it, I can't have it. Crap.

dylangs1030 15y ago

To clarify this a bit for non-Emacs users (as I saw a comment), the tl;dr version is that jwz wants Mac to maintain the Emacs key bindings that essentially amount to a specialized set of copy, cut and paste functions in text editing. 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.

Someone 15y ago
Clarification of this for those interested in history: The original Mac did not have control keys; I guess NextStep had some Emacs bindings. When Mac OS and NextStep gave birth to Mac OS X, it was possible to keep both sets, as there could not be clashes. I am not sure those Emacs bindings 'officially' exist, though (the human interface guidelines mention the use of the control key for accessibility, but not for text editing)

sambeau 15y ago

Just to be clear, these are standard Shell keybindings that Emacs also uses—not 'Emacs keybindings'.

drv 15y ago
Emacs had them first; shells copied them.
- deleted 15y ago
  [deleted]
- sambeau 15y ago
  Well that's me shattered.
cstejerean 15y ago
I believe they are actually emacs bindings. These bindings originates in emacs and were then used by readline. Software that uses readline then acquires these bindings, including bash, etc. So I wouldn't say that these are standard shell bindings that happen to be used by emacs, since they originated in emacs and shells happen to use them.
- sambeau 15y ago
  Thanks. I've been living a lie for years. :)

feralchimp 15y ago

Great comments thread on that post, including this gem after WebKit is fingered as the wrongdoer: "Two different libraries to implement text-field editing -- because, you know, that's somewhere you might want to diverge and innovate." LOL.

jvdh 15y ago
Makes a whole lot of sense to me. Text input in a browser should be handled a lot more carefully than text input to "regular" system applications.
- waitwhat 15y ago
  Why? What is so special about the browser? (or is my sarcasm detector failing again?)
  - JonnieCache 15y ago
    Browsers get used as word processors, chatrooms etc.
  - dexen 15y ago
    Unlike most desktop apps, browsers interface user directly with the internet, and it is dangerous out there. For example, theres' case of stealing text from copy/paste buffer http://news.ycombinator.com/item?id=3314004 http://news.ycombinator.com/item?id=3314004
    - dfxm12 15y ago
      More and more desktop apps are interfacing the users with the Internet though, especially when you extrapolate Apple's model with their app store. It is just as dangerous "in here" too...

prawn 15y ago

"Update: Holy shit! I am told that this bug was fixed FIVE HOURS after I posted this -- Webkit bug 73888 [1] and the patch [2]. Thanks, Alexey!" 1. https://bugs.webkit.org/show_bug.cgi?id=73888 2. https://bug-73888-attachments.webkit.org/attachment.cgi?id=117988