Community
Participate
Working Groups
Whenever the caret is moved to a certain position in the java editor, the corresponding java element is automatically selected in the outline view. It seems currently impossible, using public API, to implement a view reacting to this kind of "light" selection: the java editor directly tells the outline view to change its selection, but the ISelectionService knows nothing about it. A workaround (not verified) could be I guess to listen to selection changes in the outline view, but what if the user did not open it? For now the only way I can think of doing it is accessing the JavaEditor, which is an internal class, and use reflexion to call the protected computeHighlightRangeSourceReference() method. Not exactly clean...
For performance reasons the editor's selection provider excludes cursor movement but the post selection provider doesn't do so. You can use a post selection listener: getSite().getPage().addPostSelectionListener(ISelectionChanged);
Actually I'm interested in getting the selected java element, not the text selection. I was not very clear in my original post when I said that the ISelectionService knows nothing about it: it indeed receives a post selection event, but the reported selection is a TextSelection, not a StructuredSelection as when an element is selected in the outline view or package explorer. It seems there is no easy/public way of getting the java element from the TextSelection. People in the newsgroup mentioned two examples of how it can be achieved, but none of them is both simple and open: - JavaBrowsingPart (in org.eclipse.jdt.internal.ui.browsing), method setSelectionFromEditor. Can be trimmed down to a quite short version, but uses internal type IClassFileEditorInput. - ASTView plugin: I did not look in a great detail so I don't know about internal classes, but the implementation is quite big. - I also had a look at AJDT's Cross references view, and I saw they copied the full computeHighlightRangeSourceReference() from JavaEditor. I didn't check in detail but it seems to indicate a rather convoluted implementation. Maybe there should be a utility method somewhere to obtain the JavaElement that corresponds to a given TextSelection? I wrote one (attached), which is simply a trimmed version of the JavaBrowsingPart code.
Created attachment 26200 [details] A utility class for determining the java element that corresponds to a text selection
We don't want to encourage this and you can convert the text select / caret location to different things.
Sure we can do lots of interesting things with the text selection, but it seems determining the corresponding java element is something that is done quite frequently, as shown by the three examples I mentioned (I guess there are much more). Why is it that you don't want to encourage it?
each post selection listener that's added reduces the typing speed.
The issue is that plugin authors who want this behavior will eventually find a way to implement it. The situation gets worse if the platform doesn't support it: all the plugins that want to be notified of "light" java element selection have to perform the conversion from text selection to java element. If the java editor somehow reported structural selection, this work would be done only once. Moreover plugin authors don't necesarily know the optimal way to implement that. To adress the typing speed issue, plugins that want that kind of notification should provide the user with an option to enable or disable it. That's what the Outline view does ("link with editor" option). Of course the utility class I proposed is no solution to this problem!
What we could investigate to provide an IJavaSelection which would inherit from ITextSelection and which could lazily return additional info. This info could then be cached if computed once. How does this sound?
Sounds fantastic! It could have a method to return the current java element, and another one to return the precise AST node the caret lies on (that would be like 2x fantastic, more or less)
I find this discussion interesting and helpful, because we have the same problem in XML .. as would any language. And ... if I can admit my confusion ... what's the advice then? If "post selection" is to "provide" selection changes based on cursor movement, what *does* the selection provider provide? Is it alwasy literally when the selection span's one character or more? Also ... how does "post seletion" and "selection provider" interact? Apologies for "hijacking" this bug, but would appreciate a pointer. (and double apologies if already in the java doc).
>If "post selection" is to "provide" selection changes based on cursor movement, >what *does* the selection provider provide? Selection provider would provider the same as now i.e. reports when then selection changes except if old and new selection are both empty. >Also ... how does "post selection" and "selection provider" interact? The providers don't interact.
When we provide this we have to consider that clients might need the selected Java element from the selection in another (non-UI) thread, i.e. define the life-cycle of the selection. NOTE: - if clients do this in another thread then they need to check whether the element still corresponds to the selection at the time they post back to the UI thread - if clients do this in the UI thread they slow down typing and hence this should only be done if it is really cheap.
