Bugzilla – Full Text Bug Listing
| Summary: | [Keybindings] Java code formatter (shift+ctrl+F) formats wrong file (build.xml instead of java file) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Sergey Bushkov <sbushkov> | ||||
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | daniel_megert, eclipse.felipe, Michael_Rennie, prakash, remy.suen | ||||
| Version: | 3.6.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Sergey Bushkov
Created attachment 188007 [details]
screenshot - wrong file changed by formatter
Works fine on Windows XP but is indeed broken on Linux (3.6.1 and 3.7 M5). This looks like a platform dependent bug in the command/handler service. Paul, can you take a look? Hmmm, I don't even get the KeyDown for the F on linux. Now to find out where it went. PW (In reply to comment #3) > Hmmm, I don't even get the KeyDown for the F on linux. Now to find out where > it went. But you see that it formats the XML file? Just as a background: Ctrl+Shift+F does not work on some GTKs. Therefore we defined an additional binding. Here's how it looks like:
<key
sequence="M1+M2+F"
contextId="org.eclipse.jdt.ui.javaEditorScope"
commandId="org.eclipse.jdt.ui.edit.text.java.format"
schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"/>
<!-- alternative for some gtk input modes -->
<key
platform="gtk"
sequence="ESC CTRL+F"
contextId="org.eclipse.jdt.ui.javaEditorScope"
commandId="org.eclipse.jdt.ui.edit.text.java.format"
schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"/>
And Ant (XML) does this:
<key
sequence="M1+M2+F"
contextId="org.eclipse.ant.ui.AntEditorScope"
commandId="org.eclipse.jdt.ui.edit.text.java.format"
schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"/>
<!-- alternative for some gtk input modes -->
<key
platform="gtk"
sequence="ESC CTRL+F"
contextId="org.eclipse.ant.ui.AntEditorScope"
commandId="org.eclipse.jdt.ui.edit.text.java.format"
schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"/>
Of course this doesn't explain why the command is triggered in the non-active editor.
Yes, I can reproduce reliably. On my linux (RHEL6 based) I do not get the 'F' KeyDown event ... it's not even being processed in Widget.gtk_key_press_event(*) PW CTRL+SHIFT+F is turned into a menu event, which is why I don't see a key event. TextOperationAction$1.run() line: 131 BusyIndicator.showWhile(Display, Runnable) line: 70 TextOperationAction.run() line: 129 RetargetTextEditorAction.run() line: 237 RetargetTextEditorAction(Action).runWithEvent(Event) line: 498 ActionContributionItem.handleWidgetSelection(Event, boolean) line: 584 ActionContributionItem.access$2(ActionContributionItem, Event, boolean) line: 501 ActionContributionItem$5.handleEvent(Event) line: 411 EventTable.sendEvent(Event) line: 84 MenuItem(Widget).sendEvent(Event) line: 1258 Display.runDeferredEvents() line: 3540 Display.readAndDispatch() line: 3161 OK, ready for this: 1) on GTK+ we set accelerators on the MenuItems for "Ctrl+Shift+[0-9A-FU]" as a workaround for bug 42009 2) when we open the ant build file, it creates one of these MenuItems at the bottom of the Edit menu 3) when we switch to the Java editor, that menu item still exists (because we won't update the Edit MenuManager unless the user opens that menu). 4) CTRL+SHIFT+F goes to the menu item, which is still tied to the ant editor, and voila. Opening and closing the Edit menu before CTRL+SHIFT+F allows it to work with the java editor (this is not a workaround, merely an observation). PW Felipe, do we not have to guard against "Ctrl+Shift+[0-9A-FU]" anymore in GTK+? If I take out my accelerator hack from org.eclipse.jface.action.ActionContributionItem.update(String):860 CTRL+SHIFT+F then works correctly in both ant and java editors. How can we find out what version of GTK that 0-9A-F became no longer a problem? PW (In reply to comment #9) Not sure about [0-9][A-F], maybe it's safe to remove the guard; but Shift+Ctrl+U brings the underline "U", and waits for digits. For example, (Shift+Ctrl+U, 2, 1, Enter) inserts "!" both in eclipse java editor and gedit and gnome-terminal. (In reply to comment #9) > Felipe, do we not have to guard against "Ctrl+Shift+[0-9A-FU]" anymore in GTK+? Not sure, see: http://hpux.connect.org.uk/hppd/hpux/Gtk/Development/gtk+2-2.22.1/readme.html It reads: Release notes for 2.10 ====================== * The hexadecimal Unicode input feature has been reworked. It no longer blocks the use of the sixteen Ctrl-Shift-<hex digit> key sequences. Now it only uses Ctrl-Shift-u. ----------- I can confirm on my machine that Ctrl+Shift+[0-9A-F] does nothing. I have to hold Ctrl+Shift, hit U, then enter the hex for the code point I want. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. |