-
-
Notifications
You must be signed in to change notification settings - Fork 364
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BSP] - Support for workspace/reload
#986
Comments
I'm not sure, we can implement it in the current design, as the whole BSP server is implemented as an opaque mill command. Mill very well supports reloading (with it's |
I'm not extremely familiar with all the mill terms, so my apologies if I get some of the lingo wrong. But in this case, by finish the BSP/start target do you mean terminating the BSP connection?
Depending on what you mean by unexpected output here it's important to remember that all the communication during the connection must be able to be parsed as JSON-RPC, if not you run into all sorts of issues. This happened with sbt here, and it caused the server not work correctly with neither IntelliJ or Metals with certain versions. Again, it depends on what you mean by output here, but just make sure any weird output isn't piped into the actual BSP communication that isn't part of the spec.
Well the client will handle the lifecycle of the the connection, and end with a request to shutdown and then exit as outlined here. As for a restart, not really part of the BSP spec, but in the Metals case we have a Mainly, I think it's helpful to think of it in terms of flow of how it will be used with a client. Again from a Metals perspective I'll outline what we'd like to ideally have happen.
I think however Mill implements stage 3 it's just important (if possible) to not rely on any special logic in the client specific to Mill, but simply stay inline with the spec. That's probably easier said than done, but it makes it way easier for clients to deal with various BSP servers. |
Thanks for your comment. As an outcome, I think we should not implement our BSP support as a |
I think that's a good idea. That will also allow us to better control what goes on stdout, since as a Command, there will be some time where Mill might log to stdout before reaching the BSP code (e.g. |
I started a draft pull request: #1093 |
Forget about #1093. I already closed it. I largely refactored Mill BSP support and it now supports a new mode of operation, which also support |
@ckipp01 How does Metals know, that an edition of |
Hey, good question. There is a couple things behind the scenes happening that Metals uses to trigger this. Basically in LSP world when a user makes a change to any file and saves it that sends a After that if you follow it a bit you see that this will eventually get called and it will do a check to see if the file is a build related file: If it does recognize it as a build file, it then calls Then this will actually trigger the reload: |
@ckipp01 Thanks for the insights. After looking into |
FTR, I opened build-server-protocol/build-server-protocol#235. |
I think in part it's due to the first build server for BSP being Bloop, and there is really no way for Bloop to know what those files are, since in reality it knows nothing of your "build" files, but only the structure via the json it reads up. So it'd never be able to tell the client "hey, if any of these files change you should reload", hence why this has always been a request from client -> server. With sbt now having BSP support, Mill as well, it might make sense to dive deeper into this to see if something like this could be done. |
Feature Request
A part of the BSP spec that doesn't seem to be implemented yet in the Mill BSP is support is the
workspace/reload
request. This is useful for editors like Metals so when the user edits their build file, we can detect it and send a reload request for the server.The text was updated successfully, but these errors were encountered: