search

inko-lang / inko

A language for building concurrent software with confidence
http://inko-lang.org/
Mozilla Public License 2.0
869 stars 38 forks source link

Implement LSP server #365

Open yorickpeterse opened 1 year ago

yorickpeterse commented 1 year ago

In GitLab by @resolritter on Mar 14, 2023, 19:02

Please provide an LSP server for Inko such that users can have better language support within their editors.

I'd vouch for the following features to be implemented first:

haarts commented 10 months ago

I like where this project is going and am looking to, potentially, make a contribution.

Implementing an LSP is something I wanted to do for a while now and this might be the excuse I'm looking for. I immediately have a question: In your ast crate you define the parser. Why did you choose to go the custom route instead of using something like Chumsky or Treesitter?

yorickpeterse commented 9 months ago

@haarts Treesitter as far as I understand isn't really suited as a parser for a compiler. In particular, its initial parse times tend to not be great. As for Chumsky: I never heard of it before, hence it wasn't considered.

Setting that aside, parsers aren't difficult to write and I'd like to maintain full control over the compiler stack. Parsing libraries in turn have a tendency to fall apart once you want a bit more control, better error messages, or just not deal with tons of abstractions built on top of each other.

Aside from that, this particular issue isn't available for contributors. It's scheduled as part of the NLnet funding we're receiving (see this post for some more details), and the funds for this particular issue can only be received if I'm doing the work. A full list of the issues part of this fund are found here.

A language server is also something that's complex enough that I really want to look into it myself, as I want to make sure it's set up in a way that I feel works best :smiley:

For issues that can be worked on by contributors, refer to the issues with the "accepting contributions" label.

haarts commented 9 months ago

Good that I reached out then!

Alright, I'll hang back then. Good luck!

yorickpeterse commented 9 months ago

From the Coffee Compiler Club Discord:

There is a lot of information on LSP but people don't tell you what is the minimum that you need to build. So here it is:

  • Read and write json messages
  • Read from stdin and write to stdout
  • Implement following incoming messages:
    • initialize
    • shutdown
    • textDocument/didOpen
    • textDocument/didChange
    • textDocument/didClose
  • And publish following messages when you see a document is opened or changed:
    • textDocument/publishDiagnostics
  • In response to initialize only capability to need to specify is textDocumentSync - without this you won't be sent the textDocument messages.
  • In publishDiagnostics you can report syntax or semantic errors.

You create a standalone executable, and then hook it with a simple TypeScript wrapper.

VS Code extension requires the TypeScript wrapper, other IDE's may have different mechanisms

The json message specs are at https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/

With above minimum build, you can provide users realtime diagnostics as they code

Although the diagnostics are limited to syntax and semantic errors, this is a huge help for a new language

You can implement all of above without using any library or crate or packages, I did it in plain old C.

yorickpeterse commented 1 week ago

Interesting article regarding LSPs: https://www.michaelpj.com/blog/2024/09/03/lsp-good-bad-ugly.html