Hi, thank you for the pull request! This looks quite cool!

The location for the feature looks good to me.
The layout is indeed a bit unfortunate, perhaps it would be better if the inlay hint was immediately after theimport (orqualified in the case ofimport qualified)? In theory, we could also display itafter the module name, but that doesn't feel as nicely.

Regarding configurability, usually we try to have as little configuration as possible as it requires twice the amount of tests, so I think we should just decide on a way to display thepackage imports.

I haven't read the code, yet, but is the inlay hint displayed also when the user already added somePackageImport?
I imagine this feature works best, if the user doesn't align imports and maybe usedImportQualifiedPost?

Thanks@fendor

I'm fine with not configuring it, but while I would leave it enabled by default, I can imagine many people wouldn't like it.

Played around a bit with positioning and IMO it looks best afterimport /import qualified
As you mentioned, ideally the user doesn't align imports and doesn't qualify them or pushes them to the end withImportQualifiedPost

Good point about the case when the user already added somePackageImport, I'll handle it.
Once we agree on how it should be displayed I'll also add some tests

In an ideal world, it would be nice if inlay hints could replace appropriate amount of spaces, but I don't think that's possible :)

Added

• Displaying afterimport orimport qualified with 1-space padding on the left
• Handling cases when the user already specified somePackageImport
• When usingImportQualifiedPost, displaying hint afterimport
• Tests

I'm still worried that without any configuration options, this change won't be as welcome, but otherwise, it's ready for review.

This seems great! I think the big challenge is just "where to put it?". I think the main constraint is that Inlay hints are supposed to look the same as the text that they would insert when triggered. So I don't think we can put it at the end of the line.

Given that we're showing them in the right place syntactically, I don't see how we can avoid messing up people's formatting. We generally don't try to match this (see also the inlay hints for imports, which can't easily match people's preferred formatting either).

So overall I don't see much alternative to what you're doing. I do think this is likely to be a bit of a "love-it-or-hate-it" feature, so we probably will need the ability to turn it off!

Sorry for taking so long to come back to you!

In addition to the above (configuration option), I think it would make sense to hide the implementation in a Rule, similarly to howinlayHintProvider does it.
At last, it may also make sense to piggyback off the ruleImportActions to avoid work duplication, asImportActions already traverses the Imports.

The code itself looks good to me, I have no comments right now.
My only question is regarding the use ofGetParsedModule, why did you decide to only use the parsed module?