difficult to know which item to select in the code completion menu

[MahmoudMohi63]

When creating new widget and typing the new keyword before it for e.x. new Conta and clicking tab I do get the full completion for that widget (new Container()). When I don't use the new keyword and try to tab for autocomplete a just get the widget name like so Container

i updated to 2019.1.1
i get 3 of everything when i press tab for auto just get name like so Text or Container

at version 2018.3.6 i get 2 item
when i try to press enter or tab at (MaterialApp ( package...)) auto complet just get (MaterialApp)

but when i press tab at MaterialApp ({Ke.... auto is work fine

i dont need to use new or getting 2-3 item how to fix this? i just want this

Version info

flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, v1.2.1, on Microsoft Windows [Version 10.0.16299.15], locale en-US)
[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[√] Android Studio (version 3.4)
[√] IntelliJ IDEA Community Edition (version 2019.1)
[√] VS Code (version 1.33.1)
[!] Connected device
! No devices available

Plugin: dart and flutter

[devoncarew]

@lambdabaa has done some work here

I think you're seeing a difference between 2018.3 and 2019.1 - the newer version supports a feature to show completions for symbols that aren't in scope. This does mean that there are a lot more symbols to show. In the case where you're not typing new, I think you're seeing both the type name (MaterialApp) and the constructor for that class (MaterialApp()).

@lambdabaa, I believe that a not-yet-in-stable iteration will show additional details in the code completion view?

[lambdabaa]

Thanks for raising this issue! We do have a couple of changes in the works to improve this situation.

The first one was JetBrains/intellij-plugins#650 which makes it so that we always show the exporting library even if there are parameters (for example, in the case of a constructor). I will check to see which 2019.1 Dart plugin versions, if any, includes this change.

A second improvement was made in analysis server last week https://dart-review.googlesource.com/c/sdk/+/103561 to tell the IntelliJ plugin

1. which libraries are already imported in a file and also
2. which library each suggestion originates from.

I am working on a Dart IntelliJ plugin patch this week to use those bits so that, if a library that exports a token is already imported, we will filter not-yet-imported completion suggestions for that token.

We don't have a plan yet for the more general option to prevent duplicate suggestions altogether, but perhaps this could be implemented as an opt-in Dart IntelliJ preference. Wdyt @scheglov @alexander-doroshko?

[alexander-doroshko]

Regarding the first problem "The same class appears 3 times because there are 3 ways to import it".

• If a class is available with existing imports then I think it's ok not to suggest other variants at all (or it already works like this?).
• If we need to add an import in any case, I'd be happy if the server could find "the best one" and suggest only it. This way we'll have only one item for each class. Note that I'm not an experienced Dart developer, so I'm not sure if it's possible to find "the best import" and how important is the feature to show all available paths to the same class. But I understand and confirm that seeing the same class several times is confusing, especially for beginners.

Regarding the second problem: "Both class and constructor are suggested". Such two items look very similar and effectively the difference is only in parentheses insertion. Again, I'm not a pro Dart dev, but I'd be happy if the server could decide which suggestion is better and give only one of those.

In any case, I'd be happy not to add any options to the IDE UI.

[scheglov]

• Yes, we are moving in the direction of not including suggestions from other libraries, if there is already a suggestion for the same element from an already imported library. But I think this is not implemented on the IDE side (at least I have not seen this PR :-)).
• DAS has a way to indicate "the best import" with IncludedSuggestionSet.relevance. We give lower relevance to deprecated libraries, and higher to already imported libraries (which is now superfluous with the previous item). We can change this on DAS side without IDE changes.

[alexander-doroshko]

Yes, we are moving in the direction of not including suggestions from other libraries, if there is already a suggestion for the same element from an already imported library. But I think this is not implemented on the IDE side

Isn't it purely a server-side change? What changes does it require on the IDE end?

[scheglov]

It does require changes on the IDE side, because it is suggestion by suggestion decision.

For example a.dart might define A and re-export C from c.dart.
And b.dart might define B and re-export the same C from c.dart.

Now, if the target library target.dart imports a.dart, we want to have only the a.dart suggestion for C, but we still want to include both a.dart and b.dart into includedSuggestionSets because they have unique A and B suggestions.

So, the client should use existingImports to remember that target.dart has C from a.dart and avoid including C from b.dart into the completion popup.

[lambdabaa]

@scheglov @alexander-doroshko So I have a patch open to leverage the completion.existingImports in Dart IntelliJ, but the client preference I was thinking about was something extra. This patch only helps the case where one imported library declares the name. In the case where no already-imported libraries export a name but multiple, not-yet-imported libraries export it, we have this issue regardless.

The client preference would say "never suggest the duplicate names / displayUris" or similar. Wdyt?

[scheglov]

I don't think we need such preference.

When there is a choice, it is up to the user to make it - DAS does not know whether to choose package:flutter/material.dart or package:flutter/cupertino.dart.

When the user has already made his choice by importing package:flutter/material.dart, it is reasonable to re-use this choice for other widgets available through this import.

[alexander-doroshko]

When possible we prefer not to add any options to the UI.