This works around the setBinding calling back into the client, which
would cause the LSP to panic as there already was a mutable reference to
the document cahce held.
No need to transfer ownership!
Also use `Url` directly instead of wrapping that into a
`TextDocumentIdentifier`. That way we can burrow the URL and do not need
to clone a `Url` into a `TextDocumentIdentifier` just so we can borrow
that.
* Do not use wasm build in conjunction with `preview` to keep code lense
support on. Add `preview-lense` feature instead.
* Improve which parts of the LSP are kept based on these features.
With this patch a LSP built for the online-editor is about 10KB smaller
than before.
- We should not panic if the base type is invalid
- We should try to keep bindings in the Element even if the base type
is invalid
- Fix querying the element at a position in case it is not in the last
component of a file
Use the zero-line based lsp range/position types for the QueryProperties
lsp command results and convert them to monaco editor ranges for correct
text extraction.
Implment a command in the LSP that can be used to query all known
properties, where those are declared and defined.
With this information we should be able to provide an property editor in
IDEs.
Make the previous patch typesafe by enabling the "proposed" feature in
the `lsp-types` crate, so that the `InitializeResult` has the
`offsetEncoding` field.
Fix the fallout of this change.
We can't use file system call to load files with wasm, we need to go through the vscode API
Note that this is all async, so i had to prevent re-entry within the compiler using a rentry trick.
I removed the lifetime in the TypeLoader because I thought this was going to be necessary
to get 'static futures. But it turned out not to be necessary. Anyway, I kept it htis way because
it is actually nicer IMHO, even if the CompilationConfiguration is now copied
This refactor the LSP to be possible to compile for wasm.
When using wasm we can't use the lsp-server crate because that one use the
stdin/stdout to communicate.
Instead, we need will do the communication in TypeScript using the vscode
language server protocol library, and serialize the types to wasm. Fortunately
that's easy because the lsp-types crate contains all the serialized types.
This also "duplicate" the extension as a web extension that do not use process
to start the LSP, but use a web worker. Some of the extension code could
be refactored to avoid some duplication (like the status bar handling and such).
And add a "browser" entry point in the package.json
Finally, add a browserServerMain.ts entry point for our worker, it will try to load
the wasm code.
Currently this doesn't wirk: the browserServerMain.ts can't load the wasm.
Also todo is to write the code so that the wasm code can send the response and
notifications.
To debug, I type these commands in editor/vscode directory
npm run compile-web
code --extensionDevelopmentKind=web --extensionDevelopmentPath=$PWD ../..
