Show HN: Multilspy – Cross platform framework to develop Language Server Clients(github.com)
github.com
Show HN: Multilspy – Cross platform framework to develop Language Server Clients
https://github.com/microsoft/monitors4codegen
3 comments
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?
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?
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
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
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
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
That's a great idea, thanks for sharing
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.
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.
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
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
There is a list of supporting tooling under the official LSP site, but it's not very descriptive: https://microsoft.github.io/language-server-protocol/impleme...
That's what I used, indeed not very comprehensive
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.
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.
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)