Code completing a named parameter doesn't show me the types that could go there

[sethladd]

I wonder if we could show all the types of Decoration we have, when trying to code complete decoration: in a Container?

Here's what we see now:

Those options aren't useful, unfortunately. However, since we know that decoration: takes a Decoration, could we show the options for Decoration here? (e.g. BoxDecoration)

I'm still learning the Flutter APIs, and bouncing back and forth between API docs and my IDE is less than efficient. I want to code complete my way to success! :)

Thanks!

[devoncarew]

/cc @danrubel, re: adding type info in for named parameters (perhaps just passing Elements in for those completion items would do it?)

[sethladd]

Because Flutter loves to use named parameters in constructors, this would be a big win. Thank you! :)

[pq]

We could do some better filtering (false doesn't make sense for example) but really we want the user to type new... and once they do, we want really good completions. Here we could do some filtering and possibly sorting based on good bets.

cc @lukechurch

[pq]

AI @pq: look at what proposals we get from new.

[sethladd]

why do I need to type new? Sometimes I might want const. Or, sometimes it's a static or enum that goes here.

[pq]

Well, new (or const) are a good cue (and currently required to get the completion engine thinking that you're in a creation mind-set). It's an interesting question whether we should get more opinionated here.

@sethladd : in an ideal world what completions would you like to see? All extenders/implementers of Decoration?

@danrubel : thoughts?

[sethladd]

All extenders/implementers of Decoration?

Yup! Even if they come from statics or enums available to me.

[pq]

From chatting with Dan, this could be improved with suggestions based on type matching. Infrastructure is in place and the issue can be solved generally. That said, will investigate with the decorations case as a driving force.

[pq]

@danrubel to investigate.

[sethladd]

Great, thanks!

[mit-mit]

@pq is this an analyzer issue or an IJ issue?

[pq]

Analysis server.

cc @danrubel

[scheglov]

https://dart-review.googlesource.com/c/sdk/+/42882

Without the change:

With the change:

[sethladd]

Nice improvement!

What happens if I try to complete without first typing "new" or "const" ?

For example:

padding: <code complete>

[scheglov]

No changes here.
Do you have ideas?

[sethladd]

As long as we don't do what the screenshot in #998 (comment) is doing, then I'm happy :)

(Put another way, if I try to code complete immediately after a named parameter, show me ONLY what I can put there (both variables whose types match, as well as constructor calls that apply), don't show me variables whose types don't even match.)

[scheglov]

It always raises a question of "transitive applicability".
In the code below b is not of type A, but it has something of type A.
If we don't help users to complete b (a long name in real cases), it would be not nice.

class A {}
class B {
  A a;
}

void foo({A a}) {}

main(B b) {
  foo(a: ^);
}

[sethladd]

That's fair. I assume that we won't show "true" or "false" as options in your example?

[bwilkerson]

We will. Because we don't look at the type of the thing being proposed to ensure that there is a chain of invocations that will get you the type of thing you need. (Hence, we can't know that there isn't.)

[sethladd]

Oh, bummer. That was the original request. :)

In a world with optional new/const, we can expect that developers won't first type 'new' or 'const' in order to trigger the useful code completions.

Are there other completion models here that assume new and const won't be used, but also return the more likely/useful options?

true/false/const/etc just aren't useful :(

[danrubel]

IMO it's all about the "relevance" of the suggestion. In this situation, types that match should have a higher relevance than suggestions that do not, and the IDE should display suggestions ranked by the relevance returned by the analysis server... more relevant suggestions first.

[bwilkerson]

Well, const might be useful if it isn't in a constant context so that the user needs to be explicit.

But that aside, there are two things I can think of that we could do. The first is what Dan said: to prioritize suggestions that already have the right type over those that don't, so that less useful ones show up lower in the list. I do think we should do that.

The second is to special case true and false and just don't show them unless the target type is bool, Object or dynamic. I dislike special casing things, and I suspect that if we get the relevance right we won't need to.

[devoncarew]

In this situation, types that match should have a higher relevance than suggestions that do not

This sounds like a pretty elegant solution - we'll still show all correct suggestions (and allow users to compete through a few expressions to their end goal) but will show the most immediately useful suggestions first.

[mit-mit]

+1 for sorting matching types higher!

[scheglov]

No prioritizing matching types yet, but this CL will include constructor invocations for implicit creation. So, you can complete padding: ^ to EdgeInsets.all().

[sethladd]

Nice! I see this screenshot starts with "EdIn" ... Does the same result happen if you code complete immediately after the : ?

[scheglov]

Yes, I actually activated completion right after : and then typed EdIn to filter the list. Alternatively I could scroll it down to these items.

[sethladd]

Well then, double nice! :) Thank you!

[scheglov]

OK, we can prioritize completion suggestions in Dart Analysis Server.

Unfortunately IntelliJ has its own opinions about completions and their relevance.
I had to make some hacks into IntelliJ code itself to make it closer to the behavior I would like.
Actual change of IntelliJ completion behavior might happen, or not, I don't know. @alexander-doroshko

Here, nothing is typed yet, but the suggestions with compatible types are on the top, and sorted alphabetically.

[sethladd]

Wow! The top results look very relevant and useful.

[mit-mit]

Very nice!

[scheglov]

And one more fix, for completing imported enums.

So, you can complete Column(crossAxisAlignment: ^) and get all of the CrossAxisAlignment constants right away for selection. Or you can start typing center and by the time when you typed first letters, you get several completion suggestions. There are several enums with center, but because we give compatible types higher relevance, the correct one is always the first.

Don't pay attention to CrossAxisAlignment in the middle, it is still the same hiccup of IntelliJ's attempt to re-prioritize our already prioritized suggestions. Hopefully this can be disabled, Analysis Server really knows better about types.

[sethladd]

@scheglov yes yes yes yes yes you are on 🔥

[scheglov]

I consider this issue fixed now, at least Analysis Server side of it.
We now prioritize useful suggestions.
If there is anything else, please open new issues.

[sethladd]

Thank you very much!

[InMatrix]

This is awesome! Thank you.