Allow `Ctrl` + `Click` to open include files on `.yaml` files

[FMorschel]

Inside .dart files, we allow users to CTRL + Click on the import URI to open the file in question. I'd like to request that we do the same for .yaml files for doing the same. So if I am in analysis_options.yaml and I include from a package, I can see what I'm depending on.

CC @bwilkerson @DanTup

[bwilkerson]

So if I am in analysis_options.yaml and I import from a package, I can see what I'm depending on.

I'm not sure what you're suggesting. When you click on an import URI it refers to a single library, so it's reasonable to open the file that is the root fragment of the library. In an analysis options file you're stating dependencies on packages. What would you like to have opened when clicking on the name of the package? Or is there some other place you want to navigate from?

[FMorschel]

Sorry, I should've been more clear. I mean:

include:
  - package:very_good_analysis/analysis_options.yaml
  - package:very_good_analysis/analysis_options.7.0.0.yaml

Things like this or whatever lint package we use. I'd like to be able to see the exact file I'm including. And since the first file above is currently actually only including the 9.0.0 version, this should work in whatever .yaml file we open.

[FMorschel]

Actually, we could do that for any file in the include list of an analysis_options.yaml. That might be a safer bet and we can track those down from a single location.

We could also allow the other things like opening the package pub (lint docs) page and similar for these files we allow for the base analysis_option.yaml files. WDYT?

[bwilkerson]

Thanks for the clarification. Yes, it's reasonable to support navigation from an element in the include list to the file being included. (I was mostly confused by the use of 'import' rather than 'include'.)

Actually, we could do that for any file in the import list of an analysis_options.yaml.

Now I'm confused again. Did you mean 'the include list'? If so, yes, every file in the list should be treated the same way.

We could also allow the other things like opening the package pub page and similar for these files we allow for the base analysis_option.yaml files.

What would the use case for such a feature be? In other words, what would a user be trying to do that would prompt them to want to open the page for the included file's package on pub.dev?

[FMorschel]

When I wrote this I was awake for many hours and I wrote something other than I was thinking, sorry 😅. I'll review the wording on my comments above to say include rather then import.

What I wanted to say would be allowing users to open the lint page on the website. So say I'm on my own analysis_options.yaml with an include only. So if I open that included file, I now see all of the lints written, but I may not know what they do, so allowing the user to open the docs for them would be ideal IMO, even more so because if they have not written any lint to their own file.

[bwilkerson]

There has been discussion in one or more other issues about

• linking from the name of a lint to the documentation for the lint, and
• displaying the documentation for a lint in the hover when hovering over the lint.

I think both are worth considering, but they're completely separate, in my mind, to the question of being able to navigate from URIs in the include list.

[FMorschel]

linking from the name of a lint to the documentation for the lint

This is already done for the base analysis_options file.

they're completely separate

I agree. I simply mentioned this here because opening the included files here and not iteratively so we can see all of the files in question would make little sense. And from that thought, we currently allow the above to work only on the base file, so I questioned to make sure we think about that too. I'll be sure to open another issue later about this. Thanks for the discussion!