HN Explorer

Show HN: Multilspy – Cross platform framework to develop Language Server Clients (github.com)

38 points by LakshyAAAgrawal ↗ HN
multilspy is a cross-platform library that we have built to set up and interact with various language servers in a unified and easy way. Language servers are tools that perform a variety of static analyses on source code and provide useful information such as type-directed code completion suggestions, symbol definition locations, symbol references, etc., over the Language Server Protocol (LSP). multilspy intends to ease the process of using language servers, by abstracting the setting up of the language servers, performing language-specific configuration and handling communication with the server over the json-rpc based protocol, while exposing a simple interface to the user.

Since LSP is language-agnostic, multilspy can provide the results for static analyses of code in different languages over a common interface. multilspy is easily extensible to any language that has a Language Server and currently supports Java, Rust, C# and Python and we aim to support more language servers.

Some of the analyses results that multilspy can provide are:

Finding the definition of a function or a class (textDocument/definition) Finding the callers of a function or the instantiations of a class (textDocument/references) Providing type-based dereference completions (textDocument/completion) Getting information displayed when hovering over symbols, like method signature (textDocument/hover) Getting list/tree of all symbols defined in a given file, along with symbol type like class, method, etc. (textDocument/documentSymbol)

9 comments

[ 2.8 ms ] story [ 21.5 ms ] thread
zachallaun
Neat!

As someone who has contributed to a language server, I've wanted a language/editor agnostic way to interact with it, primarily for the purposes of black-box testing. I wonder if this could be useful for that?

What's the process for adding support for a new language?

oDot
That's pretty cool.

I'm the author of vleam[0], which enables Gleam usage in Vue SFCs.

If there's one thing I missed building the LSP is an awesome-list, where I could find stuff like Multispy -- LSP resources weren't easy for me to navigate as a beginner.

[0] https://github.com/vleam/vleam

mdaniel
It is, of course, hit or miss whether someone chose to add the topic to their repo[1], but I have found that browsing the GitHub topics for things to be a much more up-to-date list than any awesome-list which relies on both submissions and PR approval - like some kind of "wiki over postal mail"

https://github.com/topics/language-server

https://github.com/topics/lsp

FWIW, GitLab has a similar system https://gitlab.com/explore/projects/topics/language-server

1: and here's my semi-annual plea to anyone at GitHub to allow submitting repo topics via a PR process, since there are quite a few repos that would really benefit from the discoverability afforded by topics but the repo authors sometimes don't know or can't be bothered, but may very well merge a PR containing (e.g.) .github/topics.yaml

oDot
That's a great idea, thanks for sharing
udbhavs
This is my first time reading about Gleam and it looks really cool! How's the experience of writing Vue components in it? Web frameworks like it and Svelte tend to liberally meddle with the syntax & semantics of JS through transpilation to have a specialized dev experience, so it can be difficult to use a different language and feel like a first class citizen since it's not like using a simple API anymore (unless there is special consideration given to it like ReScript and React).

Also, what's the concurrency story like? Gleam does not seem to support async/await but apparently it has colored functions when compiling to JS, though I'm not sure how those interop with the JS ecosystem.

oDot
vleam does not use Vue's `<script setup>`, but instead transpiles to a regular `<script>` block, so it does not rely on specialized syntax.

It works surprisingly well, and Gleam, being such a simple language, is a joy to code in. The main issues are honestly vleam itself -- the LSP is a bit finicky and the Vite plugin needs more work, as it sometimes requires a full restart and tends to transpile excessively. I expect most of this to be solved soon enough.

As for concurrency, the `fetch` usage example sums it up fairly well:

https://github.com/gleam-lang/fetch/tree/main

antmarti
I love the idea of a centralized wrapper for spawning various language servers.

As the maintainer of a language server which is primarily used in VSCode, we've relied on community contributions to add support for other editors (NeoVim, Atom, Rider for example). Information about how to do this is spread out, prone to breaking (depending on how well the implementor understood the domain), and also requires the IDE user to follow manual steps in some cases. I don't even know where I would go or who to speak to if (for example) we changed our download URL format, or added new process architectures.