[Alpha] Language Server Protocol #969
Conversation
|
Also a reference implementation of the current working mappings can be found in the existing |
| [ImportingConstructor] | ||
| public HoverHandler(IEnumerable<IRequestHandler> handlers, DocumentSelector documentSelector) | ||
| { | ||
| _definitionHandler = handlers.OfType<IRequestHandler<TypeLookupRequest, TypeLookupResponse>>().Single(); |
There was a problem hiding this comment.
How is multiple languages supported? E.g. in the Cake PR we register a second handler of this type.
There was a problem hiding this comment.
I came to that realization last night, and added a comment about changing that around. I'll be thinking about that today and probably figure out a decent solution fairly soon.
The note wasn't near that code however
omnisharp-roslyn/src/OmniSharp.LanguageServerProtocol/LanguageServerHost.cs
Lines 105 to 107 in f9af5e2
There was a problem hiding this comment.
Great! This is how we currently resolve C# version of the handler we are overriding in Cake https://github.com/cake-build/omnisharp-roslyn/blob/da3b227582f949e2c378d6280ab0b237811228a2/src/OmniSharp.Cake/Services/RequestHandlers/CakeRequestHandler.cs#L30-L45
…r based on the project system extensions
|
@david-driscoll, EPIC! Do you accept PRs to this branch if I could find some time for helping out with endpoint mapping? |
|
@mholo65 absolutely, please feel free to branch from there and create a pull request into it. I'm going to look at testing cake support if I get a chance here. |
|
@mholo65 I've made a temporary branch that integrates things https://github.com/david-driscoll/Omnisharp-roslyn/tree/temp/cake |
… correctly. Tested with cake inegration and found an issue if the filename is null, and avoid that scenario
|
Thanks @david-driscoll. What client do you use to test LSP? Could you provide some steps on how to get it up and running? |
|
I was using https://github.com/OmniSharp/csharp-language-server-protocol/tree/master/vscode-testextension . Again this was just an informal test to ensure things were working as expected. I did encounter a few bugs in the lsp server so I fixed those. To get it running, the only changes you need to make are to point it at a version of OmniSharp that has lsp support, like |
|
@david-driscoll ok, I'm working on the CompletionHandler now. |
|
@david-driscoll: you'll want to merge the latest |
Adds CompletionHandler.
|
Going to put this through as is tomorrow, if there aren't any objections. We'll continue to iterate and add handlers over the next few weeks. |
Could you wait until Monday? I'd like to get a new OmniSharp build out with a couple of bug fixes before Monday so we can use it in a C# for VS Code release. |
|
Yeah that's fine. 👍 |
|
FYI: All is good. This can be merged now to simplify development. |
| <ProjectReference Include="..\OmniSharp.DotNet\OmniSharp.DotNet.csproj" /> | ||
| <ProjectReference Include="..\OmniSharp.DotNetTest\OmniSharp.DotNetTest.csproj" /> | ||
| <ProjectReference Include="..\OmniSharp.MSBuild\OmniSharp.MSBuild.csproj" /> | ||
| <ProjectReference Include="..\OmniSharp.Script\OmniSharp.Script.csproj" /> |
There was a problem hiding this comment.
? Not ! (Clumsy me on phone)
There was a problem hiding this comment.
I have a feeling some of those references can go away, because we don't specifically get types for a given project system, we just use the metadata from MEF.
There was a problem hiding this comment.
however I will validate that in a day or two.
There was a problem hiding this comment.
I’d think it will not load unless it’s a compile time dependency. I might be wrong though :) https://github.com/OmniSharp/omnisharp-roslyn/blob/master/src/OmniSharp.Host/CompositionHostBuilder.cs#L158
There was a problem hiding this comment.
It's a dependency via OmniSharp.Stdio and we bootstrap Lsp through Stdio.
https://github.com/OmniSharp/omnisharp-roslyn/blob/lsp/src/OmniSharp.Stdio/Program.cs#L36
We need to make a unified bootstrapper or rename stdio in a future change.
|
Hello, I am interested in testing this with https://github.com/autozimu/LanguageClient-neovim as an alternative to https://github.com/OmniSharp/omnisharp-vim. I am using ArchLinux and I am having trouble building it, but I had great success using the precompiled binaries via the AUR package. What is the status of this? |
…ll-file-path allow plugins to be specified by a dll file path
Add DocumentSymbolHandler
|
Standard issue with mac build failing, forcing the merge to get this in so consumes can test. |
🎉🎉🎉 |
Epic: #968
This is the first step in getting LSP support integrated into OmniSharp.
Lsp packages have been pushed to nuget here and here.
This starts consuming them, the branch
lspmay be long lived, or we may merge into master a few times, we haven't discussed this yet.For testing I was using the test extension from the csharp-lsp repository, and simplying making sure that OmniSharp.exe was invoked with -lsp or --languageserver and it will negotiate with language server mode automatically. It would be great to get others feedback using this against language server 2.0 vs 3.0 (that vscode implements).
Note: not all endpoints currently map 1:1 to LSP, more information on lsp can be found here and the C# implementation here
Parts done:
/gotodefinition/findsymbols/updatebuffer/changebuffer/codecheck/filesChanged/formatAfterKeystroke/formatRange/codeformat/highlight/autocomplete/findimplementations/findusages/gotofile/gotoregion/navigateup/navigatedown/typelookup/getcodeactions/runcodeaction/rename/signatureHelp/currentfilemembersastree/currentfilemembersasflat/gettestcontext/metadata/packagesource/packagesearch/packageversion/projects/project/fixusings/checkalivestatus/checkreadystatus/stopserver/open/close/diagnostics/v2/getcodeactions/v2/runcodeaction/v2/getteststartinfo/v2/runtest/v2/debugtest/getstartinfo/v2/debugtest/launch/v2/debugtest/stop