Editing on Language Server side - VSCode Extension

[jmenzies12]

Hey there,

Context:

We have hooked up GLSP and Langium in a VSCode extension and are using code actions to translate edits from the GLSP side into TextDocumentEdit's that can then be applied to the TextDocument. This bit works fairly well.

The GLSP and Langium server side are connected via SharedServices. This lets the diagram load from the document directly as well as access validation markers etc. We took some inspiration here from the Langium-Sprotty crossover.

However we are running into a bit of trouble when trying to actually apply the edits. From our point of view it would make sense for the GLSP server to apply the edit to the document directly on the server side, rather than going back around to the language client.

This is where the problems come in, editing the TextDocument by using TextDocument.update results in the document being correctly updated on the server side, however it is now out of sync with the actual document in VSCode itself (ie. it does not show up in VSCode).

If we instead apply the edit by using TextDocument.applyEdits and then write the resulting edit via the file system, this works fine if the document is not open in VSCode, however if the document is open it will not apply the edit until the user navigates to the DSL and clicks the little popup box that says there is a change.

Question:

Is it possible to edit LangiumDocument/TextDocument's on the Language Server side and then sync with the Language Client? Or is this really going against the whole design?

We have tried sending the edits from the server to the client via connection.applyEdit. However this results in a bit of a mismatch when it comes to undo, since the edit is not originating from the diagram client it cannot undo it directly.

Kind Regards
Jonathan

[msujew]

Hey @jmenzies12,

generally, language servers operate on a master-slave model. Meaning that any change is first supposed to go through the client before this change then triggers a server update. Therefore, any change originating from the server needs to be applied on the client side first.

However this results in a bit of a mismatch when it comes to undo, since the edit is not originating from the diagram client it cannot undo it directly.

I'm not too familiar with GLSP. However, the way I would attempt to on about this is to generate the change that the view is supposed to apply and send it via a custom lsp notification to the client. The client sends that directly to the webview, which then generates and applies an undoable edit from that data. This way, the data flow and undo stack stay consistent. Does that make sense?

[jmenzies12]

Hey @msujew,

Okay that makes sense about how the language server operates, I was starting to get that impression whilst digging into this.

What you said in regards to routing the change via the client also makes sense. I've been looking into that and it definitely seems like that is the right way to do this, however I think I'm running into problems with CustomTextEditors vs CustomEditors. I'll get in touch with GLSP and see if they have thoughts on this.

Thanks for your advice :)