Add new "Go to Import" option

[FMorschel]

I'd like to propose a "See import line(s)" on classes/methods from classes or extensions/functions/global variables.

Like:

import 'dart:math';

void main() {
  max(1, 2);
}

In the above example, there would be a way to access this in the "max" and it would take you to the import line (here you could alias it or whatever).

And if there was a conflict between multiple imports it could select all with multiple cursors.

[dart-github-bot]

Summary: The user proposes adding a "See import line(s)" feature that allows users to navigate from a class, method, or variable to its corresponding import line, even when multiple imports exist. This feature would enhance code navigation and understanding.

[keertip]

@FMorschel , how does this show up in the editor? Context menu? Code actions (an option in the light bulb menu)?

[FMorschel]

@keertip the current CL (https://dart-review.googlesource.com/c/sdk/+/387387) should work with an action on the context menu. Similar to the Go To Super option.

class A {}

class B extends A {}

If you right-click on B you will get an option Go to Super Class/Member. It will change your selection to the declaration of A.

It would be something like this but with an optional list to see all imports. Similar to the "References" (F12) on VS Code where you can see every call to something, you would be able to see all imports that are importing that specific name.

For the following case, both imports would show if you called it on StatelessWidget, Widget, BuildContext or Placeholder.

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

class MyWidget extends StatelessWidget {
  const MyWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return const Placeholder();
  }
}

@DanTup is there anything else?

[DanTup]

Yep, that sounds right to me. Note that it will require Dart-Code changes, it won't show up anywhere automatically. We can also choose whether it's in the context menu or not, or only in the command palette (the context menu is good for discoverability, but it's not particularly contextual in the VS Code editor, so opening the context menu anywhere will show it, even in blank spaces and comments).

[bwilkerson]

@jwren @alexander-doroshko

This is functionality that I think we should have in IntelliJ as well. I think it will be even more important when 'enhanced-parts' ships because there will potentially be multiple lists of imports spread across multiple files, making it harder for users to figure out where a given name is imported from.

The current implementation defines a custom LSP protocol for this purpose. I don't know whether that would be sufficient for IntelliJ, but I'd appreciate it if you could think about it and let me know what kind of support would be required.

[alexander-doroshko]

Just brainstorming...

Maybe we could use 'Highlight Occurrences' action for this.

'Highlight Occurrences' doesn't require any action, it just works as the caret moves.

In IntelliJ IDEA, it's possible to 'lock' highlighting by pressing Cmd+F7 (the official action name is 'Find Usages In File'). Once locked, it will make occurrences highlighting a bit more visible, and highlighting will stay even if the caret moves. It's possible to quickly navigate to the next/previous highlighting using Cmd+G/Cmd+Shift+G.

Also, the 'Highlight Occurrences' feature is used in IntelliJ not only for references, but also to highlight all return points, or all places that may throw any or a specific exception.

Some examples from Java.

Highlighting on caret move:

Locked highlighting, caret moved elsewhere:

Caret on 'return':

Caret on 'throws':

Caret on a specific exception:

Cmd+F7 shortcut on 'throws' may be interactive and give a choice:

Cmd+F7 on a specific exception gives a choice as well:

Speaking of Dart import statements, I'm not sure a popup with options is needed, they might be highlighted unconditionally.

Note that the IntelliJ's Dart plugin currently doesn't use 'Highlight Occurrences' feature from the Analysis Server. The feature currently works as a side effect of the navigation data. So it can't work for anything else than references to the same declaration, and the references must have the same text. Hopefully, we'll switch to the 'Highlight Occurrences' feature from the Analysis Server.

[DanTup]

I'm not sure that would work..

In the current legacy protocol implementation, all occurences must have the same length, and they all must be in the same file. For LSP (Document Highlights) they must also all be in the same file. But because of part files, imports can be in a parent file.

It's also not unclear to me from the screenshots above if you could see the full list of occurrences without them being on screen? I might be on line 1000 of a file with a diagnostic saying my reference of Foo is ambigious, and want to see which imports are providing two different Foos (and those imports might be in different files).

The way this will work in VS Code (the LSP command is done, but there's some work in the VS Code extension to do) is similar to things like Find References and Go to Super... it can be invoked explicitly and will provide a set of results that are ranges from the same or other files.

[alexander-doroshko]

because of part files, imports can be in a parent file

fair point

if you could see the full list of occurrences without them being on screen?

only as stripes on the scroll bar (in this example different stripe colors mean read/write field access)

[FMorschel]

@alexander-doroshko, do you think I should reopen this for this discussion?

[alexander-doroshko]

do you think I should reopen this for this discussion?

So far, I don't see the need to reopen