Community
Participate
Working Groups
I20050527-0010 There are some situations where only very few code completions make sense. - Within a generic wildcard signature after the '?', where only the 'extends' and 'super' keywords make sense (bug 93119). - Within the modifiers of a method, where only modifiers make sense We should try to avoid showing templates in these situations. See bug 93119 - we should not show the 'else' and 'elseif' templates in these cases, or at least rank them lower than the correct keywords. Should investigate whether there is an easy fix for RC2 that does not break custom templates.
Approving for RC2 but time-bound the investigation to 1 hour.
We cannot make the templates go away, as the only means that templates have to determine whether they are applicable to a certain context is the prefix in the document. So, the 'else' template will always show up for an 'e' prefix. However, templates that do not match an available keyword should rank lower than the keywords. This is a trivial fix in o.e.jdt.ui...TemplateProposal.computeRelevance: as the comment says, templates should rank *lower* than keywords, so TEMPLATE_RELEVANCE should be 1, not 2. Note that the proposals are bumped up by JavaCompletionProcessor if they match a keyword, so this change only affects templates that have no matching keyword proposal. Dani, ok to fix the relevance for RC2?
Approving for 3.1 RC2.
fixed > 20050608
Tom, Trying to verify. Can you give me an example of how I can verify that the ordering has changed? Thanks.
- have the source below (| is the caret) public class NoHeader<X e|> { } - invoke code assist expected: extends, else, elseif (we can't remove the templates) not expected (how it was before this fix): else, elseif, extends
Verified using I20050610-0010
