Actually, if I’m reading this correctly, neovim is hard-coded to communicate with the language server only via stdin/stdout. This will unfortunately take some time to hook up, since it involves routing JUST LSP related communication to stdin/stdout, and all other communication to another pipe. This seems relatively easy for the standard TerminalClient, but it seems like there are a lot of printf's that need to be removed as well
If someone has more expertise with pipe trickery, maybe there’s a more straightforward solution here? If this is a blocker for NeoVIM I can prioritize getting this working.
@scztt This is great news, thanks for developing this!
Neovim seems to only handle stdio for language server communication at the moment. (Quoting from the the nvim documentation :help lsp)
Communication with the server is currently limited to stdio.
I was thinking about creating a wrapper of sorts to begin trying this out in Neovim. It could be a standalone executable that spawns an instance of sclang and can receive JSON RPC via stdin and forwards that to sclang via a TCP socket (and then the other way around for responses). Does this sound like something that might work with the current implementation of the language server?
But unfortunately its not working yet! There seems to be an issue when trying to connect to the sclang TCP port (the server connection seems fine). I need investigate a bit more, it was also a while since I used the node.js API so I might have forgotten something simple…
Ah very cool, I’ll can look at what might me missing from this soon? Here’s where we’re spinning up the connection in the vscode plugin - I’m not 100% sure, but I think it depends mostly on stock node API’s?
Thanks @scztt, I changed the client adapter to send UDP packets instead of TCP and it seems to work!
Neovim’s LSP client is now able to send requests to the SuperCollider language server, but I think there might a problem with parsing the JSON RPC messages on the SuperCollider side. I will continue investigating… if you want I can open a new issue and post the (SuperCollider) stack trace in the LanguageServer.quark repo?
I really appreciate this thought and work. Both @scztt and @madskjeldgaard (and many others) are always on this, which is so well beyond me at this point.
I love and have been using the sc-nvim plugin for neovim @madskjeldgaard - this was quite honestly (per other posts or comments) my actual first adventure into neovim . But catching the drift. I’ve used VS Code for various things, before that (or along with) Atom, before that Sublime Text, and on an on. If what I understand from this LSP, this would be astounding to say the least. Sadly, now I only open SCIDE for immediate grab of the setup file. What is great is the help system though as well. I haven’t taken the time at this point to delve into getting help to work in nvim, but mostly rely on browsers. Then again I’m very far behind you all.
Point is, this makes sense. IDE agnostic. You all rule!
And I want to say. The SCIDE is killer. I mean that to all who helped on that front. I’d still say as a newbie this is the best place to start.
@davidgranstrom Your stdio wrapper should now work out of the box with the SuperCollider Language Server - I was able to run the vscode LSP implementation against it using a completely vanilla stdio-based configuration, so hopefully that will resolve things for neovim as well. Let me know if you see any issues.
LanguageServer: LSPDocument now supports incremental updates, and isEdited property. This won’t matter much in a usability sense, but incremental updates should be much more performant than re-sending the entire document on each keystroke
LanguageServer: Add a missing JSON class for JSON encoding. Note that this conflicts with an almost identical class in the relatively old API quark. The behavior should be identical, and a few minor issues have been fixed, but if you see error messages and are using API, this is why.
Hey! Some more triage for NeoVim would be helpful - so far VSCode is the only client I’ve gotten working, so I’m sure there will be some bugs / client-specific pitfalls in the implementation so far.
Here’s a GitHub ticket for the first part of that work. It should provide some information about what the requirements are. Both this thread and @davidgranstrom’s script are good starting points as well.
I’m happy to triage anything that comes up - please file them as comments on that ticket or as GitHub issues since it’s a bit easier for me to track them that way. I just pushed a bunch of updates to the LanguageServer quark and the vscode client, so things should be in relatively good shape!
Happy to take contributions, my ability to spend time on this is intermittent so of course it will all go a LOT faster with help
I’ve got a backlog of things that need implementing here: SuperCollider vscode support · GitHub
The “todo” column is in priority order, so if anything near the top of the list looks interesting, I’d happily accept help on it.
Also, as a smaller but still incredibly useful task: JUST getting the vscode extension set up (see the README), filing any issues that come up, and proposing pull requests where the documentation could be improved would be a massive help.
I now have a new code formatter working with LanguageServer.quark, based on @lnihlen’s amazing Sparkle sclang parser. This allows you to format code from sclang itself (both in the context of the language server, and for use-cases like sclang-based code views). It also resolves most or all of the longstanding buggy / incorrect formatting issues with the ScIDE formatter. I’ll push this feature soon, but it needs some general clean-up and unit tests. This one is pretty exciting, since formatting was the last large feature missing from the vscode plugin that made it not usable for me for day-to-day SuperCollider work.