Community
Participate
Working Groups
The current approach to visualize cross references is rather limited. When we find a reference to an object, we basically display it's nearest container in the find references view. This is not really helpful for most languages, e.g. Xtend. Consider an Xtend function foo with def MyType foo(MyType param) { var MyType something = .. .. return result as MyType; } The only element that is exported from Xtend is the function itself. Every type references in a child of that function thus the find reference view shows 4 times some.package.some.Type.foo - XtendFunction as a child node under the resource node. Even if the label for the function would be more precise, the matches wouldn't help, still. I think categorized nodes like "cast expression", "return type", "parameter" or "variable declaration" would greatly improve the result. I assume it wouldn't hurt to load the refering resource to determine a more precise label by applying the label provider of the actual refering object. It would even be possible to put a platform:/resource proxy into the cross reference feature to allow the label provider to resolve the reference quickly - if necessary. Furthermore I propose to introduce an API that allows to create a more sophisticated tree view per resource to visualize the matches. This enhancement request is somehow related to bug 309267. Loading a resource may become even cheaper as soon as we can use the caching infrastructure as described in bug 359824
Personally, I like the JDT-way of showing these results. Note that it does not show anything smaller than methods. That's in complete analogy to the "indexed container" approach. There is a difference between what is shown and what is indexed. In JDT, imports are not listed as references to the imported element, which also makes sense. We could extend the IXtextSearchFilter to also filter IReferenceDescriptions. I agree that showing the hierarchy of indexed container elements to the reference in the tree would make sense, as well as summarizing multiple reference e.g. from within the same method in a single node, as in JDT "(x matches)". I don't like the idea of loading resources just to compute labels for references.
(In reply to comment #1) > Personally, I like the JDT-way of showing these results. Note that it does not > show anything smaller than methods. That's in complete analogy to the "indexed > container" approach. They show inner types that are defined in method bodys, too. E.g. search for XtextResource and expand the matches in arithmetics.ui/InterpreterAutoEdit. That is the tree shows containers of containers, too. > There is a difference between what is shown and what is indexed. In JDT, > imports are not listed as references to the imported element, which also makes > sense. We could extend the IXtextSearchFilter to also filter > IReferenceDescriptions. JDT hides imports by default (similar to code folding). They can be visualized by unticking the filter settings in the search result view. Please note that the hierarchy will be (by default) ProjectName - package.name - FileName // the class - someMethod(ParamType, ParamType) // result type is missing - FileName.java // the file (?) - import declarations // as a logical group - imported.type.Name > I agree that showing the hierarchy of indexed container elements to the > reference in the tree would make sense, as well as summarizing multiple > reference e.g. from within the same method in a single node, as in JDT "(x > matches)". I'd like these numbers on each node. Furthermore I'm really interested in the quality of the reference, e.g. whether it's a variable declaration, a method call on the target type, an instance of or similar. I could even imagine a filtering for those kinds. > > I don't like the idea of loading resources just to compute labels for > references. I'm not really fond of this idea either, but I'd really like to see the complete method signature e.g. for Xtend functions. I've no idea how we could derive that from an EObjectDescription without resolving cross references to build the description which sounds really less appealing to me by an order of magnitude :-)
