search

jupyter-lsp / jupyterlab-lsp

Coding assistance for JupyterLab (code navigation + hover suggestions + linters + autocompletion + rename) using Language Server Protocol
https://jupyterlab-lsp.readthedocs.io
BSD 3-Clause "New" or "Revised" License
1.79k stars 145 forks source link

Standalone transclusions are not reusing connections anymore #959

Open krassowski opened 1 year ago

krassowski commented 1 year ago

Standalone documents represent fragments of code which are independent of any preceding and following code. An example in IPython is (each block represents a cell):

x = 1
%%python
print('I do not have access to `x` as I am a separate process')

There used to be a logic for reusing connections for standalone documents, which greatly improved performance (without it LSP becomes unavailable in the standalone document for 1-2 seconds while a new connection is established; it also risks saturating the number of websockets etc)

https://github.com/jupyter-lsp/jupyterlab-lsp/blob/ff8b6c44d5a81a7bc051604ea37a5bc4da6ec94a/packages/jupyterlab-lsp/src/virtual/document.ts#L477-L503

This was removed when the code was moved upstream to @jupyterlab/lsp - it is no longer in chooseForeignDocument. The removal was not complete as unusedStandaloneDocuments was retained, even though it is no longer populated.

It might be possible to monkeypatch the VirtualDocument downstream to restore this logic, or to restore this upstream but it might benefit from a larger refactor as arguably it was not very well written (it should be a responsibility of connection manager, not virtual document).

Before I start working on it I would like ask for some community support to indicate whether there is a need for this - if you are using this extension in JupyterLab 4.0 and are affected by the performance in standalone documents, please leave a comment/upvote.

krassowski commented 1 year ago

This results in a new connection being opened on every keypress within the nested documents.

image

It is quite hard to resolve here, as all the problematic logic is upstream, but does upstream even want transclusions? The overrides were removed but extractors were retained, so I got mixed messages.

krassowski commented 1 year ago

And, this also breaks diagnostics in nested documents because by the time the diagnostics response arrives the ID of virtual document has changed. only related to standalone documents

krassowski commented 1 year ago

There is a partial workaround I included earlier, but this only prevents infinite loops, not replacement of virtual document connections:

https://github.com/jupyter-lsp/jupyterlab-lsp/blob/74e0d07c51d3acf93b4c21b49019003b66a473f9/packages/jupyterlab-lsp/src/adapters/notebook.ts#L50-L77

trungleduc commented 11 months ago

It is quite hard to resolve here, as all the problematic logic is upstream, but does upstream even want transclusions? The overrides were removed but extractors were retained, so I got mixed messages.

IIRC we decided to drop the transclusion via magics but keep supporting the LSP for different cell types, that's why the extractors were kept.

gogakoreli commented 8 months ago

I agree this issue needs to be solved, because if I want to have different cells to have different language support inside the python notebook, I need to have standalone virtual documents for each cell respectively (specific use case is that I can have sql cells and python cells at the same time inside the notebook). Now this is an issue in JL4, which was not happening in JL3. As shown in the screenshot every keystroke opens a new connection if I specify standalone as true and causes infinitely duplicated lsp connection to the same cells.