Proof of concept language client

[alcarney]

Screencast_20231031_233015-1.webm

Over in the lsp-devtools repo, I now have a proof of concept language client working! It's built using textual and the BaseLanguageClient we have in pygls. It currently only supports basic document sync and completion requests - but it's a start!

Rather than trying to be a "real editor", I hope that this can grow into nice way to interact with a server while visualizing the traffic sent between it and the client

[tombh]

That's amazing 😲 For so many reasons! Have you built a text editor!? Are the tree viewer, text editor and completion modal part of textual? And the log of requests and the payload explorer are just wow, chef's kiss.

[alcarney]

All the UI elements you see are built into textual, all I've done is connect them up to our language client :)

Have you built a text editor?

I wouldn't call it a text editor yet, I haven't even implemented saving files! 😅

[tombh]

Oh okay, still impressive!

So what ideas do you have for it? It could be embedded into a web page with Pyodide? And can those requests and payloads panes be streamed as raw JSON? Then they could live as split panes in a normal editor like Vim or VSCode.

[alcarney]

So what ideas do you have for it?

I quite like the idea of giving the client multiple "personalities" where it can try its best to pretend to be VSCode, or pretend to be Vim by presenting the server with a different set of client capabilities. It would be nice not to have to setup 10 different editors just to see how your server adapts to them.

It would also be nice to try and visualize as much of the data coming back from the server as possible e.g. previewing the result of selecting a completion, without actually having to select it. - However, implementing all that will be a non-trivial task, so no idea if it would ever materialize! 😅

Then they could live as split panes in a normal editor like Vim or VSCode.

You can do that already!

The devtools component is available as a standalone app via the lsp-devtools inspect command (well, lsp-devtools tui on the current PyPi release)

And can those requests and payloads panes be streamed as raw JSON?

Yes! There's the lsp-devtools record command for that 😄 - I actually have documentation written for this one if you're interested

In order to get access to the LSP messages though, both lsp-devtools inspect and lsp-devtools record need your client to invoke the language server via the lsp-devtools agent command

It could be embedded into a web page with Pyodide?

Potentially? maybe, perhaps? I know that textual-web now exists, but don't know enough about how it works to know if it can be used for that....

[tombh]

I quite like the idea of giving the client multiple "personalities"

Oh, so that's what the Textual editor is for, acting as a chameleon editor?

You can do that already! ... lsp-devtools inspect

You think of everything!

I actually have documentation written for this one if you're interested

And of course the documentation is top tier 🧐

Potentially? maybe, perhaps? I know that textual-web now exists, but don't know enough about how it works to know if it can be used for that...

I can't help but think of a LSP Playground, where people can share and even interact with small in-editor LSP examples, all whilst seeing debug feedback. Maybe a bit ambitious.

[tombh]

Have you seen https://github.com/microsoft/monaco-editor?

I noticed it had this in its README about adding extensions:

❓ I've written an extension for VS Code, will it work on the Monaco Editor in a browser?
No.
Note: If the extension is fully based on the LSP and if the language server is authored in JavaScript, then it would be possible.

Just been thinking about embedding your idea in a webpage.

[tombh]

Oh! I hadn't connected the dots. Of course, you were already working on this. So do you think we could have a LSP-compliant in-browser editor, with live LSP debugging? And then some simple backend that lets us share things like playground.pygls.org/wK3xAa (it doesn't actually exist, just an example) that might reproduce some bug or showoff some feature!

[alcarney]

It's definitely possible, whether that's quick and/or easy to implement is another matter!

Off the top of my head there's 3 approaches we could explore.

• The option with (probably) the least amount of effort would be to
  • Add WASI support to pygls
  • Expand the VSCode Playground extension to include the message visualisation stuff (or even just enable the verbose logging!) and publish it as a web extension
  • Piggyback off of https://vscode.dev and use github repos as the storage backend
• Look into building something with JupyterLite, though I'm not sure how easy it is to hook a wasm language server into jupyterlab-lsp
• Turn Add pygls playground? #291 into a full blown custom web app, it would offer the most flexibility but would also require the most work

[tombh]

So one of the differences between approach 1 and 3 is that 1 uses the full VSCode editor and 3 just uses the Monaco editor?

I guess that the, "if the language server is authored in JavaScript" part of that Monaco FAQ answer ("If the extension is fully based on the LSP and if the language server is authored in JavaScript, then it would be possible.") doesn't mean that a Pygls LSP in Pyodide would count as "in JS"? 😬

[alcarney]

So one of the differences between approach 1 and 3 is that 1 uses the full VSCode editor and 3 just uses the Monaco editor?

Yes.

I think the FAQ is trying to say that for your LSP server to work with Monaco you need to be able to run the server within the browser itself - which typically means writing the server in JS. However, thanks to WASM, we can write our servers with pygls and just use JS to wrap the WASM program

The same limitations would exist with vscode.dev - though it can handle more of the plumbing for us

[tombh]

I think just because I have don't have so much experience with VSCode, and that I can picture the Monaco solution in my head, I imagined that the Monaco approach is easier. But it sounds like piggybacking off of vscode.dev will just be more plug and play.