terhechte/SourceKittenDaemon

Language Server Support

Opened this issue · 5 comments

terhechte commented

I'd love to deprecated the current protocol and replace it with the Microsoft Language Server:

https://github.com/Microsoft/language-server-protocol

This would buy us a lot of editor support out of the box. We already support the minimum requirements, we just need to rewrite our endpoints more or less.

nathankot commented

Nice! Given the number of frontends that are using the current API, could we namespace the support under a v2/ prefix or something similar?

Liquidsoul commented

Hi !

Sorry for jumping in 😊

FYI, this protocol would not conflict with your current HTTP implementation because it is based on JSON-RPC using stdin/stdout on the process. It may be another launch mode for the daemon though.

This would be really nice if SourceKittenDaemon supports this. This could allow the creation of SourceKit powered IDEs on Linux!

FWIW, after some investigations, maybe it would be interesting to focus all the efforts of the community on one Language Server. I mean there are already two working implementations (RLovelett/langserver-swift and owensd/swift-langsrv ) powering vs-code extensions and it was already suggested to them to focus on only one implementation.

nathankot commented

@Liquidsoul took a quick look and RLovelett/langserver-swift looks pretty good actually - have you had a chance to play around with it? What would sourcekittendaemon offer that that project doesn't?

Liquidsoul commented

@nathankot I've tried both of them and had my first shot with owensd/swift-langsrv which was giving better context info when run with its vscode plugin.
I've managed to make them work with lsp-mode in Emacs with little adjustments.

I honestly do not know if sourcekittendaemon has (or could have) an edge over these solutions.
The main difference here is that it offers Xcode project parsing while the others use Package.swift manifests. Other than that, it is mostly lacking features they have (hover at point, go to definition...)

I am just suggesting here that the creation of a Linux IDE backend should be a combined effort under one project 😃

felix91gr commented

Well... it could certainly be a combined effort. It depends on everyone’s will to work together.

This is what I think:

Counterpoint 1: competition

Wouldn’t it be better to have many projects competing to be the best language server?

Answer: since these are open source efforts, I don’t think there would be any strong incentives to have more usage than the other projects. Therefore, competition shouldn’t apply in this space.

Counterpoint: leadership

Three projects. Unified. Sounds hard. Unless everyone is willing to yield leadership to one owner, this can’t fly.

Answer: this is true. But there are many ways to make this work:

  • One “leader” that has the last word: obvious solutiom. With clear disadvantages
  • Group: everyone that is very involved votes/agrees on guidelines and workflows. Commit access is given to a small group and after that, things follow through like they do on the Swift repo.
  • External arbiter: group picks an external leader. Worst of both worlds, I guess? But this was my first idea so there might be somethin’ to it.

Benefits

If this is done well, these are the things we get in exchange:

  • More hands to do testing, bugfixing, porting, design and implementation.

  • Better vision and decision making.

  • Better representation of the community.

Then what?

One of you guys (I’m thinking Benedikt or Nathan) could start talks with the other teams to see what they think. If you think this is a good idea, that is :)