Community
Participate
Working Groups
Build Identifier: 20100917-0705 Eclipse appears to be ignoring the user's preferences for "Line Start", "Line End", "Text Start", and "Text End" key bindings while in dialogs. It's falling back on the default Cocoa bindings of 'Cmd-Left', 'Cmd-Right', 'Home', and 'End', respectively. There may be more bindings that it's ignoring and falling back onto defaults for, but these are the ones that I've noticed. Reproducible: Always Steps to Reproduce: 1. Preferences -> General -> Keys 1a. Change "Line Start" to some other key binding. Change "When" to "In Dialogs and Windows" 2. Open a file, place the caret at some point past the start of a line, and press the newly-assigned key binding. 3. Caret moves to beginning of line. 4. Right-click a file in the package explorer and choose "Rename..." 5. Press the newly-assigned key binging. 6. Caret doesn't move.
Those are text commands used in editors. There are no plans to provide this for dialogs.
(In reply to comment #1) > Those are text commands used in editors. There are no plans to provide this for > dialogs. Why not? Editors may be the targets for the vast majority of textual input, but they are far from the exclusive receivers of such. Surely a unified interface for all text input is preferable over a piecemeal one.
(In reply to comment #2) > (In reply to comment #1) > > Those are text commands used in editors. There are no plans to provide this for > > dialogs. > > Why not? Editors may be the targets for the vast majority of textual input, > but they are far from the exclusive receivers of such. Surely a unified > interface for all text input is preferable over a piecemeal one. Because the widgets should behave the same like in your OS (and most of them are actually native widget). If your OS would allow to configure this, then it would be picked up.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Those are text commands used in editors. There are no plans to provide this for > > > dialogs. > > > > Why not? Editors may be the targets for the vast majority of textual input, > > but they are far from the exclusive receivers of such. Surely a unified > > interface for all text input is preferable over a piecemeal one. > Because the widgets should behave the same like in your OS (and most of them > are actually native widget). If your OS would allow to configure this, then it > would be picked up. Hmmm, that is actually possible in OSX, but Eclipse appears to be ignoring my customized key bindings. A while back I set up my own "~/Library/KeyBindings/DefaultKeyBinding.dict" file, which is how you're supposed to customize your key bindings. That file changes my key bindings in TextEdit, but it doesn't seem to do anything in Eclipse. Does Eclipse look somewhere else for key binding definitions?
> Hmmm, that is actually possible in OSX, but Eclipse appears to be ignoring my > customized key bindings. > A while back I set up my own "~/Library/KeyBindings/DefaultKeyBinding.dict" > file, which is how you're supposed to customize your key bindings. That file > changes my key bindings in TextEdit, but it doesn't seem to do anything in > Eclipse. Does Eclipse look somewhere else for key binding definitions? Scott, would you know the answer?
(In reply to comment #5) > > Hmmm, that is actually possible in OSX, but Eclipse appears to be ignoring my > > customized key bindings. > > > A while back I set up my own "~/Library/KeyBindings/DefaultKeyBinding.dict" > > file, which is how you're supposed to customize your key bindings. That file > > changes my key bindings in TextEdit, but it doesn't seem to do anything in > > Eclipse. Does Eclipse look somewhere else for key binding definitions? > > Scott, would you know the answer? No, we don't do anything special with those key bindings. Cocoa loads and interprets them. I can't think of any reason why it shouldn't work, though -- it sounds like you're describing a new bug. Robert, could you please make a new bug for the SWT and attach your key bindings file to it?
(In reply to comment #6) > (In reply to comment #5) > > > Hmmm, that is actually possible in OSX, but Eclipse appears to be ignoring my > > > customized key bindings. > > > > > A while back I set up my own "~/Library/KeyBindings/DefaultKeyBinding.dict" > > > file, which is how you're supposed to customize your key bindings. That file > > > changes my key bindings in TextEdit, but it doesn't seem to do anything in > > > Eclipse. Does Eclipse look somewhere else for key binding definitions? > > > > Scott, would you know the answer? > > No, we don't do anything special with those key bindings. Cocoa loads and > interprets them. > > I can't think of any reason why it shouldn't work, though -- it sounds like > you're describing a new bug. Robert, could you please make a new bug for the > SWT and attach your key bindings file to it? Will do.(In reply to comment #6) > (In reply to comment #5) > > > Hmmm, that is actually possible in OSX, but Eclipse appears to be ignoring my > > > customized key bindings. > > > > > A while back I set up my own "~/Library/KeyBindings/DefaultKeyBinding.dict" > > > file, which is how you're supposed to customize your key bindings. That file > > > changes my key bindings in TextEdit, but it doesn't seem to do anything in > > > Eclipse. Does Eclipse look somewhere else for key binding definitions? > > > > Scott, would you know the answer? > > No, we don't do anything special with those key bindings. Cocoa loads and > interprets them. > > I can't think of any reason why it shouldn't work, though -- it sounds like > you're describing a new bug. Robert, could you please make a new bug for the > SWT and attach your key bindings file to it? Will do. Thanks for the response on this!
After spending some time getting my ducks in a row before posting a new bug for the SWT, I discovered that this problem actually appears to be unrelated to the OSX system keybindings. I can successfully rebind keys in the "Rename Resource" widget (A single-line edit field) and the Preferences -> Team -> SVN -> Comment Templates -> New... widget (A multi-line edit field) by using DefaultKeyBinding.dict. I think that's because those dialogs are actually OSX native widgets. However, multi-line edits fields like the SVN commit comment field, and the Bugzilla comment field are actually not OSX native widgets. They appear to be "special" Eclipse controls, since they've got the same scroll bar UI on the right side as Eclipse text editors. They are "special" in that they seem to obey only their own mysterious set of key bindings. They don't use the Eclipse ones, since changing those doesn't have any effect. And they don't use the OSX ones either, because some OSX keybinds do nothing (like Option-Up, which should be "go to beginning of paragraph"), and changing them with DefaultKeyBinding.dict doesn't work. Maybe this is a bug with the plugins that create those dialogs? I think that's the Subclipse and Mylyn plugins.
(In reply to comment #8) > However, multi-line edits fields like the SVN commit comment field, and the > Bugzilla comment field are actually not OSX native widgets. They appear to be > "special" Eclipse controls, since they've got the same scroll bar UI on the > right side as Eclipse text editors. Bugzilla fields in Mylyn are just instances of StyledText, which means they are not NSTextViews and therefore don't use the Cocoa-based key bindings. They aren't Eclipse text or code editors either, so the Eclipse key bindings for text editors won't be in effect there, either. Key bindings are implemented in NSResponder -- the message you specify in the keybindings file is sent to the view when the matching key is pressed. This would be difficult to add to the SWT because it is at too low of a level to convert those messages into something that StyledText could deal with. I think I'm turning this into an enhancement request.... This is specific to the Mac and it's at the UI level, so my first guess is that Prakash would be the person to implement it. We wouldn't have to actually read the keybindings -- Cocoa will send the commands to the StyledText's NSView. We just need to convert the corresponding command into something that StyledText could handle. Dani, it's up to you guys if you want to add support for this. The other possibility is that Mylyn could add support for keyboard commands in the task editors like they do in Wikitext.
Mylyn should either use the native widgets or if they use StyledText, they should register actions for the already existing text editing commands.
The commit dialog is provided by Subclipse. I would recommend to raise a separate request in their bug tracker. Key-binding support in the Task Editor for common commands has been improved for Mylyn 3.5 and is tracked on bug 321701. Please open specific requests if you are still missing support for text commands in the Task Editor. *** This bug has been marked as a duplicate of bug 321701 ***
