R - Support Starting/Stopping LSP

[dhruvisompura]

Details

To get LSP features working in a sensible manner for multiple console sessions we need to ensure the LSP for the active session is the only one providing diagnostics/code completion/etc.

The simplest approach to achieve the above is to only allow the LSP for the active session to be running, and shutdown all other LSPs.

The Positron API exposes a new event that is fired when the foreground session changes (#6310). The language packs can listen to this event to start the LSP for the active session and gracefully stop the LSPs for all other sessions.

---

The kernel and LSP lifecycle are closely tied together right now since an LSP only needed to be started and stopped when the kernel was started stopped. The lifecycle for an LSP needs to be disentangled from the kernel so an LSP can come and go during the lifecycle of the kernel.

Testing

• [ ]

[juliasilge]

With the state of #6714 as of right now, I believe the situation is:

• we successfully call ArkLsp.deactivate()
• then we successfully call this._client!.stop()
• the LSP doesn’t actually stop, because that isn’t implemented over on the ark side

The debounce of the extension host notification really solves a lot of bad behavior we are seeing and glosses over not everything being exactly right right now. As of this writing, a way to still see something going wrong is to have an R file up that generates an outline and then to add an additional R console. You will see two outlines present for a moment, and then it will correct itself.

We think what remains to be done is to:

• make a patch to tower-lsp in ark similar to what was done in air, so the LSP knows how to stop
• handle the state of the Jupyter comm on the ark side (this will prevent cascading race conditions regarding port availability)
• at least reset (or make local) some global state that is stored in ark

cc @DavisVaughan