Community
Participate
Working Groups
Die-hard emacs users might find some key mappings confusing. For instance, tab anywhere on a line in emacs will auto-format the line, in eclipse it inserts a tab at the cursor. I tend to hit tab constantly without thinking about it... Also, CTRL-Space in emacs will begin the selection of a region, in eclipse it starts a template completion. I cannot seem to find a way to override in c++ mode. Am I missing the correct option or procedure? Thanks
PR was not targeted to any particular release. Changing target milestone to 2.1
I tried disabling all of the bindings for control-space and it still invokes ContentAssist in the C editor, but not in the java editor. Control-space is still shown as the keyboard shortcut for Edit->ContentAssist in the C editor when the binding is disabled. I think a hard coded key binding more serious bug than a poorly chosen default binding. This problem seems to be cross platform because I'm seeing it on Linux-Gtk. Should the subject be changed to reflect that this is about more than bad defaults or should the hard coded key binding be filed as a separate bug? I think that ContentAssist should be bound to Alt+/ by default when in emacs mode because that is the key that emacs uses for word completion. Since Alt+/ is also used for ContentAssist in Chinese locales, it shouldn't conflict with any other bindings.
I've seen Ctrl-Space bring up content assist at times but not always. Alt-/ does it as well and is supposed to be the correct key combination. I'll rename this bug since the real problem seems to be Ctrl-Space, which I always used to set the mark back in emacs and annoys me to no end when it doesn't work correctly in the CDT.
> I'll rename this bug since the real problem seems to be Ctrl-Space, which I > always used to set the mark back in emacs and annoys me to no end when it > doesn't work correctly in the CDT. Something to look at for 3.0
It's actually trivial to fix this... extract the org/eclipse/cdt/internal/ui/editor/CEditorMessages.properties file from the plugins/org.eclipse.cdt.ui_2.1.0/cdtui.jar file and find the line that sets the "Co&ntent Assist" label. You'll see it has the Ctrl-Space binding hardcoded -- just remove it, replace the file in the jar et voila! There might be other hardcoded bindings. For me Ctrl-. gives me some kind of content assist (I'm new to CDT so I haven't explored it yet) instead of the "go to the next error" I set up and the Eclipse key bindings editor reports.
I forgot to mention that after you make the change the context menu shows the configured binding instead of the hardcoded one, so there really isn't any reason this should be hardcoded.
(In reply to comment #5) > It's actually trivial to fix this... extract the > org/eclipse/cdt/internal/ui/editor/CEditorMessages.properties file from the > plugins/org.eclipse.cdt.ui_2.1.0/cdtui.jar file and find the line that sets the > "Co&ntent Assist" label. You'll see it has the Ctrl-Space binding hardcoded - - > just remove it, replace the file in the jar et voila! 8-) Right .. I forgot about those ... This was the way to implement key bindings in the Eclipse-1.x days. I'm removing this now, the Key binding in eclipse-3.x is more flexible. > I forgot to mention that after you make the change the context menu shows the > configured binding instead of the hardcoded one, so there really isn't any > reason this should be hardcoded. Absolutely.
Ok, the property file contains other hardcoded keybinding .. but let's start with the content assist and see how it plays out. Flipping to fix, please verify when you get a chance with a new build. Fix in the head.
