Showing content from https://github.com/ionide/FsAutoComplete/issues/361 below:
Consider using fsprojects/fsharp-language-server as a starting point for LSP · Issue #361 · ionide/FsAutoComplete · GitHub
I recently read on @Krzysztof-Cieslak twitter that he'll be working full-time on contract with MS for the next few months, and that one of the major focuses will be finishing the LSP implementation of FSAC. Congrats!
For one moment, let me try to convince you (@Krzysztof-Cieslak) to use https://github.com/fsprojects/fsharp-language-server as a starting point for your efforts:
- Because of FSAC's history as a separate protocol, it contains a considerable amount of incidental complexity that isn't necessary in an LSP implementation.
- In contrast, fsharp-language-server is a "clean slate" implementation of LSP. Under-the-hood, it uses FSharp.Compiler.Service, just like FSAC.
- If you migrate FSAC to the LSP, you will have to support both LSP and the legacy FSAC protocol for some time, which will make the job harder.
- On the other hand, if you "adopt" fsharp-language-server and port features from FSAC to it, you can make a clean break with the past.
I would be very happy to make @Krzysztof-Cieslak , @enricosada and any other maintainers of this repo admins on https://github.com/fsprojects/fsharp-language-server. I think you could very quickly port the features of FSAC that aren't in fsharp-language-server, such as the "type hints" that appear to the right of function definitions.
If I have failed to convince you of this proposal, there are several notable features of fsharp-language-server that it would still be worth trying to replicate in FSAC:
- It builds as a standalone executable, see here. This means it has no dependencies on system-installed
dotnet, which eliminates a large category of errors.
- It's significantly faster than FSAC. This is most easily observed in large projects---open something big, like FSharp.Compiler.Service, and click around and type to see how long autocomplete takes. The reason for this is that FSharp.Compiler.Service is extremely sensitive to the exact order-of-operations you send to it, because of the way its internal caches work. By fiddling with seemingly insignificant details of how I interacted with FSCS, I was able to obtain huge speedups. I don't recall all the details, but you should be able to get FSAC to be just as fast by fiddling with the order of operations you send to FSCS, and you can use fsharp-language-server as a reference of what speed is possible.
- It contains some reusable e2e tests of cracking difficult projects and tests of LSP features. Because the LSP tests are written against the LSP protocol rather than any particular implementation, you could re-use them without too much difficulty.
On the other hand, if I have succeed in convincing you to try to "adopt" fsharp-language-server and port the missing functionality from FSAC, just let me know who to add as maintainers 😄
@cartermp FYI
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4