Community
Participate
Working Groups
"Link with Editor" neglects to expand the tree in Project Explorer for not C/C++ file types after reopening eclipse. My case: 1. Create a new subfolder in C/C++ project. Place there a new file with non-C/C++ extension like hello.txt. Open the file with text editor. 2. Quit and reenter eclipse. It should open hello.txt in editor at that point. 3. In Project Explorer, push button "Link with Editor". I expect the tree to be expanded and the cursor placed on hello.txt at that point. As a side note, the button is actually named "Link open editors with content in the Navigator" (???). Well, that appears to be absolutely true and if you open Navigator it is linked. But what about linking in Project Explorer?
I can reproduce when both CDT and Java content extensions are enabled. It works when only one of them or none is enabled. The issue is that the parent computation for the file should result in a CContainer object (from the CDT extension), but this is overridden by the Java extension in org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider.findParent(NavigatorContentExtension, Object, Object). A possible solution would be to ignore the overriding extension if the returned parent equals the original parent. Moving to Platform/UI for consideration. > As a side note, the > button is actually named "Link open editors with content in the Navigator" I think this is already covered by bug 187137.
Created attachment 125124 [details] Patch proposal This patch implements the fix outlined above. The basic idea is that any pipeline content extension which returns the same (equals()) parent as the original content extension should be interpreted as "non-overriding" so that it does not inadvertently revert the overridden parent from another extension.
This patch is very small but this problem stands on the way all the time in our workflow. May I ask for this patch to be reviewed soon? Our in-house build system provides some kind of manifest file with parameters and instructions for make (this is C/C++) in each folder. The name of the file is always the same and it has no extension. It is very much difficult to figure out which file you are in and navigate to the source folder as the path is 10 levels deep.
(In reply to comment #3) > This patch is very small but this problem stands on the way all the time in our > workflow. May I ask for this patch to be reviewed soon? Our in-house build > system provides some kind of manifest file with parameters and instructions for > make (this is C/C++) in each folder. The name of the file is always the same > and it has no extension. It is very much difficult to figure out which file you > are in and navigate to the source folder as the path is 10 levels deep. > I will try to get this into M6, or RC0. I know the change is small, but I would not commit a change like this unless I have a test case that shows the problem (which I will have to prepare and which takes time). If you want to expedite the process, I would encourage you (or someone) to add a test case for this to the org.eclipse.ui.test.navigator test suite.
Released to HEAD 3.6M7 Andrew, can you pick up tonight's nightly (N20100421) and verify this fix? Anton, thank you for your contribution; I think it make sense to align the getPipelinedParent() with the other two get methods and allow them to not influence the outcome. I changed the Javadoc to reflect this.
Andrew, can you verify this fix against any I build after I20100426?
It worked for me with I20100428-0100. Thanks for the fix.
