Bug 76674 - Code assist always proposes current type in @see tag
Summary: Code assist always proposes current type in @see tag
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 minor (vote)
Target Milestone: 3.1 M3   Edit
Assignee: Martin Aeschlimann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-20 12:53 EDT by Frederic Fusier CLA
Modified: 2004-10-27 12:57 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Fusier CLA 2004-10-20 12:53:16 EDT 
Using build I200410190941.
Test case:
	"IXX.java",
	"/**\n" + 
	" * @see IYY\n" + 
	" */\n" + 
	"public interface IXX {}",
	"IYY.java",
	"public interface IYY {}"
In IXX.java, set cursor just after @see IYY and launch completion.
Then, you get 2 proposals in the list:
IXX.java
IYY.java

This is not correct, first proposal (current type) should not be proposed!
Comment 1 David Audel CLA 2004-10-20 13:06:59 EDT 
The problem seems to be inside JavaDocCompletionEvaluator#evalTypeNameCompletions().

'currElem' is added at the end of the proposals list but this method does not
verify if the prefix match.

Move to JDT/Text
Comment 2 Dani Megert CLA 2004-10-21 09:37:39 EDT 
Martin, why do we do this?
Comment 3 Martin Aeschlimann CLA 2004-10-27 04:21:21 EDT 
We use the code assist proposals give in  type body (outside a comment).
Question to David, why is code assist's only proposal the outer type?
Comment 4 David Audel CLA 2004-10-27 05:06:55 EDT 
To perform codeassist inside javadoc, a fake import statement is added. And
codeassist does not propose types of the current compilation unit inside import
statement (it is not useful).
Comment 5 Martin Aeschlimann CLA 2004-10-27 08:58:58 EDT 
Oops, You're right, for '@see' in top level type comments it's a fake import 
statement, there it's my bug
(fixed > 20041027)

It's inside the type where the similar problem appears: In the following 
example I get 'Test' suggested, as the only type. Why?
package test;
class Test {
  |code assist here
}
Comment 6 David Audel CLA 2004-10-27 09:23:50 EDT 
When the completion token is empty, only enclosing types are proposed to avoid
to propose all the types of the workspace (rt.jar + all projects contents).
Propose too many types would not be useful (rt.jar is very big) because only the
top of the list would be seen and it would be expensive to compute. If the
completion token have at least one character more types are proposed.
Comment 7 Martin Aeschlimann CLA 2004-10-27 09:34:38 EDT 
I understand the problem with too many types and requiring a least one 
character as prefix. But why then still showing the enclosing types on the 
empty prefix? I think that's more irritating than helping.
Comment 8 David Audel CLA 2004-10-27 10:01:13 EDT 
When the token is empty the exact behavior is to propose enclosing types and
expected types.

class X {
  Y y = (|code assist here
}

In this exemple only X and Y are proposed.

We do not want to propose too many types, but propose nothing would mean that
you cannot insert a type here. So enclosing types and expected types seems to be
the less wrong subset of possible types.
Comment 9 Martin Aeschlimann CLA 2004-10-27 12:57:58 EDT 
marking the PR as fixed (see comment 5)