search

scalameta / metals-feature-requests

Issue tracker for Metals feature requests
37 stars 4 forks source link

Provide a way for users to get completions for names that aren't yet in scope #340

Open Baccata opened 1 year ago

Baccata commented 1 year ago

Is your feature request related to a problem? Please describe.

Extension methods are awesome, but their usage tends to break the flow of writing code as they require imports before auto-completion kicks in. 

val map : java.util.List[Int] 
map.asSca // doesn't offer the "asScala" completion as the necessary import is not there `scala.jdk.CollectionConverters._`

Describe the solution you'd like

I'd like a way to configure a list of completion elements that metals could use even when the information it relies on (presentation compiler/semanticdb) is not sufficient to find what the user is looking for.

For instance 

[
   "scala.jdk.CollectionConverters._"
]

would allow metals to look for completions as if "CollectionConverters" was imported in the current file, and offer what it contains as an additional completion item, that would result in the import being actually added to the list if the user selected asScala for completion.

Metals could come pre-configured with such items (jdk converters and duration come to mind), and users could add/remove to the list based on their personal preferences (json libraries, pure-fp libraries, etc)

Describe alternatives you've considered

No alternative came to mind, besides changing the predef which is highly intrusive and cannot be configured globally.

Additional context

No response

Search terms

completion, scope

tgodzik commented 1 year ago

Thanks for reporting! We currently suggest extension methods inside the workspace, but not the ones from dependencies, which is a limitation we have. I think we could possibly index some subset of extension methods inside objects that are easy to import :thinking:

julienrf commented 1 year ago

What do you think of having special support for a set of common patterns? The benefit would be that it would not rely on indexing.

Besides Java/Scala collection converters, I think it would be useful to also support 1.second and foo.tap(...).

tgodzik commented 1 year ago

We could potentially index extension methods that were used in the workspace, so that the next time you write it it would be used automatically. Plus maybe a list of well known ones? But that would be problematic if the standard library ever changed.