| 30 May 2024 |
|  lolgab changed their profile picture. | 17:02:06 |
 Tomasz Godzik | Hmm... I haven't managed to take a closer look, but it would be best if we didn't need to add another bsp server | 18:36:40 |
| Tomasz Godzik | We could go the SBT route or scala-cli one | 18:36:58 |
| Tomasz Godzik | Basically we need to provide information about any automatic imports | 18:37:28 |
| lolgab | I followed the scala-cli approach and it seems that Mill is sending the right results. I couldn't make Metals work correctly yet, but I need to try more.
The thing I miss in the protocol extension is a way for the server to say it provides this capability. In Metals there is an hardcoded supportsWrappedSources = Some(true) in the Scala cli server configuration, but in other BSP servers it is hardcoded to None, moreover there isn't any setWrappedSourcesProviders(true) to call to tell clients the server can handle that type of message. As a workaround Metals could set that value for newer versions of Mill, but it doesn't sound right.
You can check this commit for the implementation I did: https://github.com/com-lihaoyi/mill/pull/3195/commits/3254ee83b8c9638a9ee00cca20851ba4b539249f | 23:27:36 |
| lolgab | https://github.com/scalameta/metals/blob/d12e21e56f6b9559b0275c0ee0776e300de97ba8/metals/src/main/scala/scala/meta/internal/metals/Indexer.scala#L296
Also this line seems wrong if I use Mill, since the server is already sending the right generated file path, I don't understand why Metals changes it.. In my case then metals tries to open a file that doesn't exist:
out/.../millbuild/build.sc.scala
instead of the existing:
out/.../millbuild/build.scala
| 23:52:48 |
| 31 May 2024 |
| lolgab | Found how a build server can state that it supports wrapped sources... It's by sending "scala-sc" as it's supported languages.
https://github.com/scalameta/metals/blob/8f9fdd9025da12c00a559d3cadedcfa440a03b7f/metals/src/main/scala/scala/meta/internal/metals/BuildServerConnection.scala#L759-L775 | 06:58:39 |
| Tomasz Godzik | It's fine to hard code it for mill though | 07:26:52 |
| Tomasz Godzik | We can raise an issue or a pr to fix that later on | 07:27:18 |
 Tobias Roeser | Huh, how come I can't find any trace of the extension in the official BSP repo? In what way is wrapping sources special to some scala-sc language. Shouldn't it be a general feature for each language? | 07:35:34 |
| Tobias Roeser | * Huh, how come I can't find any trace of the extension in the official BSP repo? In what way is wrapping sources special to some scala-sc language? Shouldn't it be a general feature for each language? | 07:35:47 |
| Tobias Roeser | If you managed to bypass the BSP repo, are there any reasons for that? | 07:39:07 |
| Tomasz Godzik | Ach, it's specific to scala CLI then | 07:40:52 |
| Tomasz Godzik | Forgot about that, I can try and take a look later today or tomorrow | 07:42:09 |
| Tobias Roeser | In Mill we exactly the same need, since we wrap our build.sc scripts before compilation. | 07:42:16 |
| Tobias Roeser | * In Mill we have exactly the same need, since we wrap our build.sc scripts before compilation. | 07:42:29 |
| Tomasz Godzik | We could move that as an extension to BSP later on if it works for moll | 07:43:56 |
| lolgab | After adding "scala-sc" to the supported languages it starts calling the new endpoint.. But still Metals behaves funny. If I command click to a definition it points me to a non existing file .../build.sc.scala which is set as a "virtual" file in metals code (I don't know what that means).
If I Command-click to an external definition (say, ScalaModule from Mill's codebase), the offset for the build.scala is applied and instead of going to the line where ScalaModule is defined, it goes to 21 lines above (which is the number of \ns in the topWrapper sent via BSP). | 08:15:54 |
| lolgab | * After adding "scala-sc" to the supported languages it starts calling the new endpoint.. But still Metals behaves funny. If I command click to a definition it points me to a non existing file .../build.sc.scala which is set as a "virtual" file in metals code (I don't know what that means).
If I Command-click to an external definition (say, ScalaModule from Mill's codebase), the offset for the build.scala is applied and instead of going to the line where ScalaModule is defined, it goes to 21 lines above (which is the number of \ns in the topWrapper sent via BSP). | 08:25:41 |
| lolgab | lefou8453 Tomasz Godzik I started working on the PR to add the bespoke BSP command to the official protocol: https://github.com/build-server-protocol/build-server-protocol/pull/673 | 10:52:24 |
| Tomasz Godzik | Awesome! I have a very slow day today, sorry for not being more active 😅 | 11:10:33 |
| Tomasz Godzik | I think the issue with go to definition might have something to do with semanticdb. It might actually be modified by scala cli inside scripts | 11:11:56 |
| lolgab | No worries! 🙂 | 11:21:49 |
|  Thibault joined the room. | 15:36:04 |
| 1 Jun 2024 |
| lolgab | I couldn't find where this happens | 06:56:14 |
| Tomasz Godzik | It's somewhere deep in scala-cli, but we should be able to work around that in metals | 09:20:48 |
| Tomasz Godzik | Or maybe the issue is with indexing workspace sources | 09:21:12 |
|  brndt_43397 joined the room. | 18:42:44 |
| 2 Jun 2024 |
| Thibault changed their display name from tiboepfl to Thibault. | 17:01:23 |
| 23 Jun 2024 |
|  @devfuuu:matrix.org left the room. | 22:27:20 |
