Community
Participate
Working Groups
Content assist key binding is hardcoded as "Ctrl + space". "Ctrl + space" is also used for default key binding of activation of Linux Input Method. The content assist key binding must be changed in a preference. Build date: 20070405 OS: Redhat Enterprise Linux V5.0 Steps to recreate problem: 1- Start eclipse in DBCS locale such as ja_JP.UTF-8 2- Open Remote System Explorer perspective 3- Create new connection 4- Launch the remote shell 5- Enter UNIX command such as "ls" in command input field. Then, enter "Ctrl + space". 6- Both IME and content assist are activated. Expected output: Key biding of content assist must not be hardcoded. Key binding must be changed in a preference.
Created attachment 63242 [details] Hardcoded content assist key binding
What key is used in the Eclipse JDT Editor for content assist in your locale? Could you attach a screenshot of Preferences > General > Keys showing it? We should probably just re-use the existing content assist command, by registering a command handler for it. Then it should automatically use the key that's used for content assist in all of Eclipse.
I attached the screenshot of key biding for content assist. Please take a look at the screenshot.
Created attachment 63483 [details] Screenshot of ContentAssist
Dave - are you ok if I defer this to the future?
We can fix this either in 2.0.1 or 3.0. I would think it would quite easy to do.
Assigning 2.0.1 if we're confident that there is no API change.
Bulk update target milestone 2.0.1 -> 3.0
*** Bug 210138 has been marked as a duplicate of this bug. ***
I will try to prepare a patch for the upcoming BugDay.
awsome, thanks ;-)
I have created content assist handler which is binded to the default command for content assistance. This handler is global for all remote shells and when it is activated it provides content assistance for the active shell. The IHandlerService requires org.eclipse.core.expressions so I had added this bundle as a dependency for org.eclipse.rse.shells.ui. Tomorrow I will be available in #eclipse-bugs and I will be happy to discuss the proposed patch :)
Created attachment 91022 [details] Patch for this bug.
Just reviewing for now, the patch looks great to me. I love patches that actually reduce the amount of code :-) I need to do some testing of it tomorrow. DaveM can you also review / test the patch please? Radoslav can you please add your legal message as a bugzilla comment here: http://www.eclipse.org/dsdp/tm/development/committer_howto.php#external_contrib Radoslav, on what Platforms have you tested? Windows only or others as well? I'm going to test on ones that you haven't covered yet:-) I'd also love to see a Unit test but that's supposedly hard with a UI feature like this one.
Ah yes, and the copyright dates in the file headers should be increased to read ..., 2008 by IBM and others
Created attachment 91122 [details] Patch for this bug Copyright headers updated. Martin, I have tested only on Windows, feel free to give it a try on other platforms. I agree that making an unit test for this feature will be pretty tough.
I, Radoslav Gerganov, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer to make this contribution under the EPL.
Created attachment 91216 [details] JVM Backtracke from GTK Crash with the patch Hm, patch is perfectly fine on Windows (tested against Eclipse 3.3.2 Target Platform). Tried reassigning content assist to the TAB key and it worked like a charm. Undo (Ctrl+Z) also worked as expected, bringing back the previous entry from the History. I tested on a Windows-Local shell. On Linux (tested against Ecilpse 3.4M5) there were problems: * Undo (Ctrl+Z) did not work at all, no action. I tried again on 3.4M5 without the patch, and it worked - so that's clearly a regression. * Reassigning content assist to the Tab key and trying it on a Linux-Local shell made my JVM crash with a SEGV, see below. This was on an RHEL4 box. Given that the bug was reported against PC-Linux-GTK, I'm reluctant applying the patch into CVS if it can have such negative impact... though that might not be the patch's fault. Anyways, it needs to be investigated. Radoslav, do you have a Linux box available for testing? My Linux box is RHEL 4 (Nahant Update 3), Sun Java 1.6.0_01-b03, gtk2-2.4.13-18, gtk+-1.2.10-33 /usr/lib/libgtk-x11-2.0.so.0.400.13 # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00a58a03, pid=12929, tid=3086875568 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode) # Problematic frame: # C [libgtk-x11-2.0.so.0+0x1e0a03] # # An error report file with more information is saved as hs_err_pid12929.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp #
Created attachment 91218 [details] Another backtrace after changing keyboard shortcuts Interestingly, the SEGV crash was not reproducable on re-start: Content assist in the RSE Local Shell viat TAB key worked just fine. Then I wen to Preferences again, and this time I changed Undo from Ctrl+Z to Ctrl+U. Pressed Apply. Back in the Command View, I just typed some characters (did NOT type Ctrl+A)... and ... boom: # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00a58a03, pid=16473, tid=3086875568 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode) # Problematic frame: # C [libgtk-x11-2.0.so.0+0x1e0a03] # # An error report file with more information is saved as hs_err_pid16473.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp #
In Eclips eclipse 3.4M5 without the patch, I cannot get the GTK crash to occur - no matter how much I change the keyboard shortcuts, press apply or actually use them in the RSE Command View. It looks like it must have to do something with the patch. Sorry Radoslav :-(
Created attachment 91357 [details] Updated patch from Radoslav against HEAD of 1-Mar-2008 Patch had to be merged due to moving NLS String CONTENT_ASSIST from rse.ui into rse.shells.ui -- new version is against HEAD as of 1-Mar-2008.
Martin, I have installed Ubuntu 7.10 on my Thinkpad T60 and I can't reproduce these crashes after applying the patch. First I have tried with Eclipse-SDK-3.3.2-linux-gtk -- clean install, checking out the latest TM sources and applying the patch. Everything was working fine just like on Windows - reassigning keys for both content assist and undo, using the keys and the context menu - no problems at all. After that I have downloaded Eclipse 3.4M5 and I have found that the Undo command is not working using the key binding and it is disabled in the context menu. However the content assist command was working fine both using the key combination and the context menu. I have restarted Eclipse several times and tried changing keys for content assistance - no problems with it. Next I have reverted the patch and I have found that the Undo command works using Ctrl-Z but it is *always* disabled in the context menu in Eclipse 3.4M5 (both Windows and Linux). Apparently, there are some issues with the Undo command in 3.4M5 which need to be investigated further. In your stacktraces the crash seems to be caused by g_main_context_iteration and bug 130840 reports the same problem. My guess is that this is GTK bug. Which version of GTK do you use? On my machine "apt-cache show libgtk2.0-0" shows version 2.12.0. I am using JDK 1.6.0_03 from Sun.
Thanks Radoslav. I tried again on the same Linux machine on top of Eclipse-3.3.2 and it worked just fine. Then I tried again on top of Eclipse-3.4M5 and could not reproduce the issue any more. My machine had rebooted since, so perhaps it was related to some odd state of the system. Anyways, I've committed your patch. Thanks again for the great work. I've commented on bug 130840 regarding the crash. Are you going to file a bug for the undo issues? It seems you investigated those more than I did. On a quick bugzilla search, I did not find any existing bug describing the issue, so I think we should file one since it appears to be a regression.
Verified that the patch is also good on Solaris 10 GTK with Sun 1.5.0 JVM.
Martin, Radoslav some questions: 1. With this fix anybody that used the SystemCommandEditor before (User Actions/Compile Commands does) no longer has content assist as adding the handler for content assist proposals to the handler service is done in the SystemCommandsViewPart. Can we move this back to the SystemCommandEditor or do clients that use SystemCommandEditor now have to add the handler themselves? This would require clients adding a dependency on org.eclipse.core.expressions. 2. Which bug did the Undo support get fixed with? It is also broken for anyone that use to use SystemCommandEditor. Thanks.
I don't have the insight to answer these questions (Rado hopefully has), but here's my 2 cents: 1. I don't see adding a dependency to org.eclipse.core.expressions for clients problematic, that shouldn't be an issue. 2. I'm against code duplication, so if we can make the Handler such that clients don't need to repeat the same stuff I'm in favor of it. Note, though, that clients who re-use the SystemCommandEditor in a different context might be interested in contributing different content assist strategies anyways, so duplicating the handler might be an advantage rather than a drawback. As said, though, these are just high-level thoughts since it was Rado who made the fix.
> 1. With this fix anybody that used the SystemCommandEditor before (User > Actions/Compile Commands does) no longer has content assist as adding the > handler for content assist proposals to the handler service is done in the > SystemCommandsViewPart. Can we move this back to the SystemCommandEditor or do > clients that use SystemCommandEditor now have to add the handler themselves? > This would require clients adding a dependency on org.eclipse.core.expressions. The content assist handler is registered in SystemCommandsView because this way it becomes available for all remote shells. I didn't know that SystemCommandEditor could be used outside of the SystemCommandsView. If we want to move the registration of this handler into the editor, we should investigate how to obtain the IHandlerService in this case and how to define the correct scope of the handler. Currently I am using the part handler service which means that the handler is active when the SystemCommandsViewPart is active. > 2. Which bug did the Undo support get fixed with? It is also broken for anyone > that use to use SystemCommandEditor. > It is bug 221392. I believe it is broken because there is no IViewSite in this case and the UndoActionHandler cannot be created (bug 231835). Could you try to set the IViewSite with SystemCommandEditor#setViewSite() to see if it works?
> > 2. Which bug did the Undo support get fixed with? It is also broken for anyone > > that use to use SystemCommandEditor. > > > > It is bug 221392. I believe it is broken because there is no IViewSite in this > case and the UndoActionHandler cannot be created (bug 231835). Could you try to > set the IViewSite with SystemCommandEditor#setViewSite() to see if it works? > Since the Work With User Actions and Compile Commands are dialogs there is no IViewSite. It seems we are tied to the view much more closely for undo/content assist now.
Comment on attachment 91122 [details] Patch for this bug Patch from Rado was eventually used.
