Inconsistent list of suggestions when trying to complete List.with

[mauromol]

Consider the following:

package test17
class Test17 {
	void foo() {
		new List()|
	}
}

Now, suppose the cursor is at "|" and start to type "." (dot): the code assist suggestion list is shown. Start to type "wi" and look at the suggestion list: eachWithIndex(Closure) is shown before with(Closure). This is unexpected and it's the cause of a lot of typing errors while coding.
In particular, see the difference when starting code assist in these different ways:
new List().| (and then type "wi")
vs
new List().wi|

In the second case eachWithIndex(Closure) is not even shown!

[eric-milles]

I am not getting eachWithIndex for either of these scenarios. Is this still an issue with 3.0 snapshots?

[mauromol]

Yes, I still reproduce with 3.0.0.xx-201801162243-e47.
Try to write new List(), then press . (dot): code assist suggestions appear (without the need to hit Ctrl+Space. Then type wi.

[eric-milles]

Can you share what content assist options you have enabled/disabled (Groovy and Java)? This behavior must be tied to one of the settings.

[mauromol]

For Groovy, just "Use closure literals for closure arguments" is checked.
For Java I have "Enable auto activation", delay 0, trigger for Java . (dot), triggers for Javadoc @#.
But if I disable "auto activation" and hit Ctrl+Space after ., I get the same.

In Java | Editor | Content Assist | Advanced I have the following proposal kinds checked: API Tools, Basic, Groovy, Groovy Template, Jar, Java (Code Recommenders) (just this for Java Proposals!), JPA, No Prefix Constructor Completions, Spring Annotation, SWT Template, Template.
In Content assist cycling I have all the entries checked except: Java Non-Type, Java Type, Word, Java (while Java Task-Focused is checked)

[mauromol]

Same behaviour if I uncheck Java (Code Recommenders) proposal kind and check Java instead.
As I said, the difference in behaviour shows when I invoke code assist before typing "wi" or after typing "wi". It seems like in the first case the "contains" logic of content assist is applied, while it is not in the second case.

[mauromol]

Got it: I don't see "eachWithIndex" if I uncheck the option: Java | Editor | Content Assist | Show substring matches.
Which is however the default I think (and I find it extremely useful).
What is wrong here is that eachWithIndex is shown as the very first suggestion.

[eric-milles]

Thanks. I'll have a look with that setting enabled -- I think it is somewhat recent. And I'll try to add some tests with it on.

[eric-milles]

I'm not sure what to do with this issue report. eachWithIndex is a qualifying substring match for wi. And the relevance sorting of the proposals is done before the popup is displayed. So your typing is just filtering the list.

[mauromol]

But doesn't a resorting occur after each typing? Tomorrow I'll try to see what happens with Java

[mauromol]

I just tested with a Java class and JDT:

package test17;

import org.codehaus.groovy.runtime.DefaultGroovyMethods;

public class Test17J {

	public void foo () {
		DefaultGroovyMethods.|
	}
}

When you invoke code assist at "|", a long list appears, showing various eachWithIndex() methods before with() methods (I think the order is alphabetical at a first time). Then, if I type "wi", the list is filtered, but suggestions are resorted and all methods whose names stars with "wi" are shown BEFORE eachWithIndex() suggestions. So definitely, the list is also resorted on each key type, not just filtered.

[mauromol]

Please see my comment in #461 about another effect of the suggestion list not being recomputed on each key type. If here the problem seems to be a missing resorting of suggestions (which causes a suboptimal code assist experience and a high rate of typing errors), in that case it even causes a missing suggestion. On my daily work experience, I don't know which of these two cases is the most annoying. :-(

[mauromol]

Hi Eric, no milestone at all set for this and #477? :-(

[eric-milles]

@mauromol I haven't looked into this or 477; if I had a plan of attack I would set a milestone. I haven't been marking content assist as Help Wanted since I have a pretty good handle on that part of the code. Much time has been spent trying to keep up with new Java, Groovy, and Eclipse releases. They have picked up the pace in the last few months.

[mauromol]

Sure, you did a great work, really! I just asked for the lack of a milestone here because these two bugs are still on the top list of the most annoying bugs for me ;-)

[eric-milles]

Substring matching was not supported for completion with a prefix pattern. That is why there was an inconsistency seen for "list." vs "list.wi". I have a change to enable support for the substring matching preference. With that, "eachWithIndex" will appear in both lists. Sorting to get "with" to display before "eachWithIndex" is the next step.

[eric-milles]

Ready to test

[mauromol]

Great work, seems to be perfect now with 3.1.0.xx-201808130148-e47, thank you! 👍

I think this is a huge improvement in a Groovy developer daily experience!