Community
Participate
Working Groups
Link with editor is implemented by means of an EAdapter on the semantic object. It has a reference to an outline node and as soon as the editor selection changes, the adapter will be queried to update the outline's selection. This does not work if the outline is not fully computed up-front. There is no adapter available, if the children of a node are never computed. The worst working solution with minimal effort would be to create the outline eagerly as long as link with editor is enabled. This leads to the situation, that people, who actually use the outline, still suffer from bad performance. Another approach would be to rewrite the selection logic based on regions (each node has an optional region) instead of actual objects.
see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=297473 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=322435
XtextContentOutlinePage now uses the regions of its ContentOutlineNodes to find the best node for a text selection and no longer uses the ContentOutlineNodeAdapter. It should thereby be able to cope much better with lazily initialized outline trees. Nevertheless, "link with editor" will cause the outline tree to be constructed entirely on the first change of the text selection. I also added a guard that avoids changing the outline selection when the text selection has not changed, therefore avoiding cycles when link with editor is enabled. This should also fix bug 322435 and bug 297473. One problem remains: The region of an outline node refers to the region returned by the ILocationInFileProvider, which normally is the region describing the name of an object, instead of the entire text belonging to the object. So selecting a text area that does not belong to an object's name, e.g. a keyword, will not select the respective outline node any more. The easiest fix would be to change the region of the outline node to be the entire text of the object, but that would be a significant change of semantics. Given we are very likely reimplementing the outline in the next release, we should be able to live with that in the meantime.
Addendum: If you know more about the structure of your outline tree, you might want to implement your own IContentOutlineNodeForTextSelectionFinder that stops digging deeper into the node hierarchy if possible and thereby avoids creating nodes eagerly.
Closing bug which were set to RESOLVED before Eclipse Neon.0.
