Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
- Aug 04, 2010 Since OS X supports custom key bindings, I looked for a way to fix this. The trick is to create a file called DefaultKeyBinding.dict in the KeyBindings folder inside your Library folder. You can use this file to override the default key bindings for most applications. Here are my changes.
- This documentation is generated automatically from the comments and commands in the DefaultKeyBinding.dict file. The script documentkeybindings.rb is free for use, but it's specifically designed for use with my formatting in the bindings plist (i.e. It's a little finicky). This project is maintained by ttscoff.
Click here to return to the 'Customize the Cocoa text binding system' hint |
Thansk ! Very interesting article.
And you had me realize that Tiger brought back the Keyboard Desktop Accessory ! Gee !
Excellent list of shortcuts. I had no idea there were so many, thanks.
And the incremental search capability is something I hoped could be made available in other apps besides Firefox. Now I have it all over, thanks again!
---
d a v e
http://www.hostwerks.com/~dave/
how did you get M-u to work as a keyboard shortcut? any of the meta modifiers that generate diacritics keep failing here.
I have the same problem. Using Option as Meta, M-c works but M-u does not.
Also the C-x bindings don't work either. C-x C-s would be wonderful. :)
darnit. Silly me. Apparently 'saveDocument:' doesn't work, but 'save:' does. I'll fix that. I thought I had tested it.
Yes. save: and saveAs: both work. Neither openDocument: nor open: seem to work though.
You're right. The diacretics make it fail. If you want to use ~u as a binding, you'll probably have to make a new keyboard layout, look at my full article. It links to an application called Ukelele which can do this.
Apparently the diacretic is getting caught at a lower level than the text system, so its shortcut won't work as a binding.
Does anybody know if there has been any work to integrate vim commands? I've searched a couple times over the past year, and couldn't find anything. My productivity would skyrocket.
I can't find any either, but I'm sure that if you did a little work to create the keybinding for it (even if it only covered the most popular vim commands), you would make a lot of geeks happy...
---
In /dev/null, no one can hear you scream
It's not very possible, because Vim is a modal editor, whereas NSTextView widgets are not. But if you want, you can try to approximate some vim bindings by using modifier keys and leaving it non-modal.
If you come up with some good vim approximations, let me know and I'll add them to my page.
Vi keybindings exist for the bash shell, a user enter inserts mode by default unless they hit esc to go into command mode for whatever reason.
I don't see why a keybinding couldn't be designed that emulated this functionality.
Because Cocoa text fields are not modal. The original poster already told you why it is not possible to do this within the context of the Cocoa classes without doing more programming than mere configuration.
while not a complete solution it is a working proof of concept, and still quite handy. i'm using it right now to write this message.
you can find viAllOver at http://www.dabble.org/viallover/
it works in most text fields of most cocoa apps, including text fields in html pages with Safari. also works in TextEdit, Mail, and SubEthaEdit to name a few.
KeyFixer - Fix Your OS X Home And End Keys
i am the author and am still looking for help. enjoy.
Are there some defaults around to modify other aspects of the Cocoa text system? In particular I'd like to turn off the 'smart' selection when deleting a highlighted word--so the space _isn't_ deleted along with the word.
Hmm. that's a weird one. It seems to depend on how you select the text. If you double click it, it will delete the space. If you drag to select, it won't. One way to avoid deleting the space is to modify the selection after double-clicking the word, and then it won't take the space out. You could conceivably make a binding to deal with this, but I'm not sure if there is any other way to change the behavior on a systemwide basis.
Haven't seen this here -- and just for completeness: the possible values for the key bindings can be found here:
/System/Library/Frameworks/AppKit.framework/Versions/C/Headers/NSResponder.h -- look under the section 'Standard bindable commands'.
Update august 4th 2011: Behaviour slightly pooped since Lion (Mac OS X 10.7). Now Home and End act as a back and forward button respectively, unless the cursor is within a text field in your browser.
Nothing I tried worked until I installed KeyRemap4MacBook (http://pqrs.org/macosx/keyremap4macbook).
This installs to your preference pane and the option is found under “For PC Users” and is called “Use PC Style Home/End”.
Everything below this point is useless, and only saved for luls.
This is how I altered ~/Library/KeyBindings/DefaultKeyBinding.dict to change the behaviour of the Home and End keys in Mac OS X 10.6.8. (The directory and file did not exist so I had to create them manually.)
{
/* Remap Home / End to be correct :-) */
'UF729' = 'moveToBeginningOfLine:'; /* Home */
'UF72B' = 'moveToEndOfLine:'; /* End */
'$UF729' = 'moveToBeginningOfLineAndModifySelection:'; /* Shift + Home */
'$UF72B' = 'moveToEndOfLineAndModifySelection:'; /* Shift + End */
'^UF729' = 'moveToBeginningOfDocument:'; /* Ctrl + Home */
'^UF72B' = 'moveToEndOfDocument:'; /* Ctrl + End */
'$^UF729' = 'moveToBeginningOfDocumentAndModifySelection:'; /* Shift + Ctrl + Home */
'$^UF72B' = 'moveToEndOfDocumentAndModifySelection:'; /* Shift + Ctrl + End */
}
Copied from http://evansweb.info/2005/03/24/mac-os-x-and-home-end-keys
Mac OS X and Home / End keys
The default key bindings for the home and end keys in Mac OS X are different to any other operating system I’ve ever used. By default, they seem to be bound to the viewport, rather than the line of text you are editing. In a multi-line document, the Home key scrolls up to the top of the document, and the End key scrolls down to the bottom. In each case the caret stays where it was.
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
- Aug 04, 2010 Since OS X supports custom key bindings, I looked for a way to fix this. The trick is to create a file called DefaultKeyBinding.dict in the KeyBindings folder inside your Library folder. You can use this file to override the default key bindings for most applications. Here are my changes.
- This documentation is generated automatically from the comments and commands in the DefaultKeyBinding.dict file. The script documentkeybindings.rb is free for use, but it's specifically designed for use with my formatting in the bindings plist (i.e. It's a little finicky). This project is maintained by ttscoff.
Click here to return to the 'Customize the Cocoa text binding system' hint |
Thansk ! Very interesting article.
And you had me realize that Tiger brought back the Keyboard Desktop Accessory ! Gee !
Excellent list of shortcuts. I had no idea there were so many, thanks.
And the incremental search capability is something I hoped could be made available in other apps besides Firefox. Now I have it all over, thanks again!
---
d a v e
http://www.hostwerks.com/~dave/
how did you get M-u to work as a keyboard shortcut? any of the meta modifiers that generate diacritics keep failing here.
I have the same problem. Using Option as Meta, M-c works but M-u does not.
Also the C-x bindings don't work either. C-x C-s would be wonderful. :)
darnit. Silly me. Apparently 'saveDocument:' doesn't work, but 'save:' does. I'll fix that. I thought I had tested it.
Yes. save: and saveAs: both work. Neither openDocument: nor open: seem to work though.
You're right. The diacretics make it fail. If you want to use ~u as a binding, you'll probably have to make a new keyboard layout, look at my full article. It links to an application called Ukelele which can do this.
Apparently the diacretic is getting caught at a lower level than the text system, so its shortcut won't work as a binding.
Does anybody know if there has been any work to integrate vim commands? I've searched a couple times over the past year, and couldn't find anything. My productivity would skyrocket.
I can't find any either, but I'm sure that if you did a little work to create the keybinding for it (even if it only covered the most popular vim commands), you would make a lot of geeks happy...
---
In /dev/null, no one can hear you scream
It's not very possible, because Vim is a modal editor, whereas NSTextView widgets are not. But if you want, you can try to approximate some vim bindings by using modifier keys and leaving it non-modal.
If you come up with some good vim approximations, let me know and I'll add them to my page.
Vi keybindings exist for the bash shell, a user enter inserts mode by default unless they hit esc to go into command mode for whatever reason.
I don't see why a keybinding couldn't be designed that emulated this functionality.
Because Cocoa text fields are not modal. The original poster already told you why it is not possible to do this within the context of the Cocoa classes without doing more programming than mere configuration.
while not a complete solution it is a working proof of concept, and still quite handy. i'm using it right now to write this message.
you can find viAllOver at http://www.dabble.org/viallover/
it works in most text fields of most cocoa apps, including text fields in html pages with Safari. also works in TextEdit, Mail, and SubEthaEdit to name a few.
KeyFixer - Fix Your OS X Home And End Keys
i am the author and am still looking for help. enjoy.
Are there some defaults around to modify other aspects of the Cocoa text system? In particular I'd like to turn off the 'smart' selection when deleting a highlighted word--so the space _isn't_ deleted along with the word.
Hmm. that's a weird one. It seems to depend on how you select the text. If you double click it, it will delete the space. If you drag to select, it won't. One way to avoid deleting the space is to modify the selection after double-clicking the word, and then it won't take the space out. You could conceivably make a binding to deal with this, but I'm not sure if there is any other way to change the behavior on a systemwide basis.
Haven't seen this here -- and just for completeness: the possible values for the key bindings can be found here:
/System/Library/Frameworks/AppKit.framework/Versions/C/Headers/NSResponder.h -- look under the section 'Standard bindable commands'.
Update august 4th 2011: Behaviour slightly pooped since Lion (Mac OS X 10.7). Now Home and End act as a back and forward button respectively, unless the cursor is within a text field in your browser.
Nothing I tried worked until I installed KeyRemap4MacBook (http://pqrs.org/macosx/keyremap4macbook).
This installs to your preference pane and the option is found under “For PC Users” and is called “Use PC Style Home/End”.
Everything below this point is useless, and only saved for luls.
This is how I altered ~/Library/KeyBindings/DefaultKeyBinding.dict to change the behaviour of the Home and End keys in Mac OS X 10.6.8. (The directory and file did not exist so I had to create them manually.)
{
/* Remap Home / End to be correct :-) */
'UF729' = 'moveToBeginningOfLine:'; /* Home */
'UF72B' = 'moveToEndOfLine:'; /* End */
'$UF729' = 'moveToBeginningOfLineAndModifySelection:'; /* Shift + Home */
'$UF72B' = 'moveToEndOfLineAndModifySelection:'; /* Shift + End */
'^UF729' = 'moveToBeginningOfDocument:'; /* Ctrl + Home */
'^UF72B' = 'moveToEndOfDocument:'; /* Ctrl + End */
'$^UF729' = 'moveToBeginningOfDocumentAndModifySelection:'; /* Shift + Ctrl + Home */
'$^UF72B' = 'moveToEndOfDocumentAndModifySelection:'; /* Shift + Ctrl + End */
}
Copied from http://evansweb.info/2005/03/24/mac-os-x-and-home-end-keys
Mac OS X and Home / End keys
The default key bindings for the home and end keys in Mac OS X are different to any other operating system I’ve ever used. By default, they seem to be bound to the viewport, rather than the line of text you are editing. In a multi-line document, the Home key scrolls up to the top of the document, and the End key scrolls down to the bottom. In each case the caret stays where it was.
As a programmer I find this behaviour to be just plain wrong— I want Home and End to move to the start and end of the current line.
I have found a way to “fix”� this problem by editing the default keybindings file,~/Library/KeyBindings/DefaultKeyBinding.dict. Create the directory and / or the file if they’re not already there, and make it look like this:
If there are already entries in DefaultKeyBinding.dict, just add the 4 new mappings above to the main section of your file.
My Defaultkeybinding.dict For Mac Os
Other more or less relevant sources:
DefaultKeyBinding.dict · GitHub
- http://www.starryhope.com/tech/apple/2006/keyfixer/ (comments)