Community
Participate
Working Groups
M1 Since the members view doesn't show types linking the view to the editor's caret should be more tolerant. For example - Object field;<cursor> should select the field - void foo() { } <cursor> should select the method - <cursor> void foo() { } should select the method, even if the method doesn't have a java doc comment
This surfaces especially in the Members view because there is no selection anymore. However, all other views and actions suffer the similar problem, e.g. the Outline view removes the selection from the field and selects the parent (type).
+1 moving to jdt.text
Adapted summary. The editor uses ICompilationUnit.getElementAt(int position) which returns the CU if the caret is after the ; Could JDT core try to guess the closest element? Otherwise JDT Text would have to do this by sending multiple calls to getElementAt(int).
The problem is that there is a match in the enclosing element, how could we not consider it ?
Just to clarify, this API is doing exactly what it is supposed based on source ranges. The fact you do not want certain type of elements may simply indicate that you would need something different, since we have existing clients would likely need this behavior. Deferring for now
I agree that we would need another method (e.g. getting the element(s) for a given range. We will try to be smarter in our area to improve navigation fro Members and Outline view.
Reassigning to inbox since there are currently no plans to work on this.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
