-
Hey everyone, I am currently trying to implement notebook support for a Langium language in VSCode. General background: The problem:
As a possible solution, I then added the notebook's file extension ( In VSCode, the code cells now load correctly and offer the expected functions of the language server. However, after the notebook serializer (simple JSON serializer) has saved the whole notebook to the file - VSCode now displays error messages, from which I can conclude that the parser now also considers the serialized notebook as JSON (which of course it cannot parse as a GM language document). ![]() The notebook still works as expected and without problems, but VSCode displays those parser errors. I am therefore not sure where the problem lies. Have I overlooked something, or has something fundamental changed in Langium or VSCode since the blog post, so that the steps are no longer sufficient? Has anyone had any experience with Langium in notebooks in more recent versions? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Hey @JanikNex, sorry for the late response. the main issue comes from the fact that you have two languages already and the service registry isn't capable of selecting the correct one for the notebook cell documents. This issue isn't exhibited by language servers that only support a single language, as the service registry doesn't need to pick - it will always return the singleton service instance for any document. The example I'm using in the blog post is based on lox, which is just a single language. The workaround you proposed has the issue that the language server will attempt to load the full The correct way to solve this is to create a specialized |
Beta Was this translation helpful? Give feedback.
Hey @JanikNex, sorry for the late response.
the main issue comes from the fact that you have two languages already and the service registry isn't capable of selecting the correct one for the notebook cell documents. This issue isn't exhibited by language servers that only support a single language, as the service registry doesn't need to pick - it will always return the singleton service instance for any document. The example I'm using in the blog post is based on lox, which is just a single language.
The workaround you proposed has the issue that the language server will attempt to load the full
.gmnb
file as a document of your language. Since this isn't the case (it's just a json file),…