Suggest Widget - Sort Declared / Inherited First

[Number-3434]

The Issue

When you want to find out possible symbols on a member, the best way to do it is to type the symbol name, followed by a dot (.), and then browse accessible members from the suggest widget.

However, the suggest widget contains lots of extra members (such as any extensions methods / inherited methods).

For example, given the following:

import 'package:flutter/material.dart';
import 'package:getx/getx.dart';

DemoClass get demoClass => Get.find();

class DemoClass extends GetxController {
  void someUsefulMethod() { }
  void anotherUsefulMethod() { }
}

if you tried to find the methods declared in DemoClass using the suggest widget, it is very hard as it also lists all inherited / extension members along with it (such as demoClass.obs, demoClass.toString(), demoClass.toJSBox(), etc.).

The Suggest should only be triggered when triggered ending with a dot (.).

Examples of symbols:

// VALID (applies to these if suggest is triggered at the end of the line)
someInstance.
SomeType.
int.
someInstance.thing.
someEnum.

// INVALID (does not apply to any of these)
SomeType
int
someInstance.thing

---

Proposal

1. Some setting to not include inherited / extensions members

2. Sort the declared members first, then inherited, the extensions members.

I understand that this may need to be added as a feature to VSCode in general, and that it may not be possible in the current circumstances.

[DanTup]

I don't think we have many good options here. While we could add a general VS Code setting, it would be inconvenient to have to toggle it to change between these modes. We also don't have any control over the sort once you start typing (because VS Code takes over), and the initial list is ranked based on some heuristics (it's not clear that declared members are always the most likely choices).

I'm curious about exactly what the goal is - you said you "want to find out possible symbols on a member" but for what reason? Are you planning on using the code, or are you using the completion just to try and discover more about the class? If the latter, would something like the Outline or Breadcrumb be more useful for viewing the declared members?

[Number-3434]

Basically, I've created a class that extends GetxController.

I have created two methods on that class, but I keep forgetting their names.

I expose an instance of that class (using singleton pattern) through GetX

If I use the suggest widget to try and find their names (which is easier than manually navigating to the source code), I get a lot of other suggestions (such as all the methods inherited from GetxController, extensions), and it is actually very hard to find the methods I actually declared.

[DanTup]

Thanks for the info. I think having a setting for this wouldn't work very well because it would be more effort to turn the setting on (and back off later) than navigating to the class. Out of interest, are these extra methods from GetxController things that you never want to see?

I ask because I wonder if extension types might be a good fit for this. My understanding is that you could create your own type that extends GetxController that exposes only the methods you want, and it just compiles away so there is no overhead (as there would be if you wrapped the controller with a real class).

(Edit: To be clear, Extension Types isn't stable yet, but I think it's coming in a future SDK release)

[Number-3434]

No, I just want them grouped.

For example, all word-based suggestions are at the bottom, which is useful since you know that once you see word-based suggestions, you're at the end, and there are no more semantic suggestions.

It would be a nice feature if VSCode supported grouping in the suggest widget.

It could then indicate that some suggestions are inside a particular group, (e.g. declared), others (e.g. inherited or extensions).

In that case, declared groups would be sorted first, then inherited, then extensions.

[Number-3434]

VSCode has Intellicode, which provides star completions that are in a custom order at the top.

Could this somehow be replicated to produce a similar effect with declared at the top, then inherited, the extensions?

[DanTup]

Unfortunately don't have control over the UI so we can't provide any groupings. We also can't control the ordering except for when there is no prefix typed (as soon as you type a character, VS Code re-ranks itself).

While we can set the ordering when there is no prefix typed, the goal is for the most likely items to be at the top (for example taking into account things like types) and I don't think pushing the declared items to the top would be the best experience. It works for Intellicode because those items are the ones it thinks are most likely to be used.

[Number-3434]

@DanTup

We also can't control the ordering except for when there is no prefix typed

Well, that doesn't actually bother me.

I actually do prefer the current sorting strategy for empty suggests.

Basically, this only applies when there is an instance / type followed by a trailing member access operator (.).

For example:

// VALID (applies to these if suggest is triggered at the end of the line)
someInstance.
SomeType.
int.
someInstance.thing.
someEnum.

// INVALID (does not apply to any of these)
SomeType
int
someInstance.thing

All I need is for the suggestions to be at the top when I type ., since I can't actually remember the method I'm looking for.

I would therefore prefer it being sorted when there is no prefix typed (i.e. just someClass. instead of someClass.a), as that is my most usual use case, as I often use that to try and find possible symbols.