Community
Participate
Working Groups
Build Identifier: 3.6.1 M20100909-0800 When java files and build.xml files are opened in the eclipse workspace, and a java editor is active, "ctrl+shift+F" formats one of build.xml files instead of the java file. Reproducible: Always Steps to Reproduce: A project contains a java file, and the ant build.xml file. 1) Open the java file in the editor; 2) Open the build.xml file in the editor; edit it; save; 3) Go back to the java file, edit it, save; At this point, both editors are saved (no '*' dirty mark). 4) Press 'Shift+Ctrl+F' in the Java editor. The java file is not changed, but the build.xml file is formatted instead (text becomes formatted, and the 'dirty' mark appears). At the same time, "Format" action from the main menu works correctly, and the "Format" action from the popup menu works correctly, too.
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.
