Re-trigger diagnostics when active session changes

[dhruvisompura]

Background

Language scripts (R and Python) get their diagnostics from the active console session for that language. Similarly, when you run code, it is always executed in the active console session for that language.

In the multiple console session world, we need to decide which session provides diagnostics for a given editor, and which session should run code when an execution request is made.

To resolve this problem, we will designate one session as the "active" console session and use that for diagnostics and execution. The user is able to change the active session. A challenge with this approach is how to manage the transition between active sessions (e.g. re-linting all the open documents at once can be jarring).

Another option would have been to maintain an affiliation between scripts/editors and sessions (i.e. a given script is associated with a given console session); users can change affiliation if needed. A challenge with this approach is how to present UX that helps users understand the binding and change it if needed

Technical Details

The language server protocol groups language features into buckets called capabilities. The client and server exchange the list of capabilities supported by each other.

• Server capabilities: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#serverCapabilities
• Client capabilities: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#clientCapabilities

The server side capability we are concerned about in this issue is called diagnostics which is how files get linted.

The language server protocol section gives additional detail on how the VS Code language features map to the LSP specifications: https://code.visualstudio.com/api/language-extensions/overview#language-server-protocol.

A language server implementation gets access to a number of events that it can listen and respond to as shown in this example: https://code.visualstudio.com/api/language-extensions/language-server-extension-guide#explaining-the-language-server.

UI

Editor features are described by the editorOption enum in src/vs/editor/common/config/editorOptions.ts. These options are provided to a CodeEditorWidget instance defined in src/vs/editor/browser/widget/codeEditor/codeEditorWidget.ts. The CodeEditorWidget contains a lists of events which pertain to certain language feature. There are events which get fired when a user takes an action, such as changing the contents for the editor.

For an example of how the CodeEditorWidget is used, take a look at the ConsoleInput component which utilizes it:

positron/src/vs/workbench/contrib/positronConsole/browser/components/consoleInput.tsx

Line 679 in fe6b71d

const codeEditorWidget = positronConsoleContext.instantiationService.createInstance(

As part of #1005, posit-dev/ark#224 contains the work that allows diagnostics to be refreshed when a command is run in the console. The refresh_all_open_file_diagnostics function in ark is the function that re-lints all open files. This function is triggered when executing a command from the console via executeCommand.

It’s also important to note that each session has its own LSP/diagnostics provider. When we switch sessions we need to make sure we proxy to the diagnostics provider for the foreground session.

Description

As part of the multi console session work, we want to ensure that switching runtime sessions causes editor features to re-trigger.

We need to determine if there is an existing event we can utilize to re-validate the editor contents. If not, we will need to determine if we can create a new event (this may not be possible since there is a protocol we need to follow?) or utilize some combination of events. Currently, language features only fully re-trigger when a runtime session is restarted, but we don't want to depend on this process to validate editor contents because it is extremely inefficient.

The UI can take two approaches to re-trigger diagnostics when the foreground session has changed:

1. Clear out the old diagnostics, then show the new diagnostics once they are received. The benefit with this approach is that the user will not see any stale data. The con with this approach is a “jittery” UI experience.
2. Do not clear the old diagnostics, and replace them with the new diagnostics once they are received. The benefit with this approach is a subtler UI experience where the user’s screen does not flash. The con with this approach is stale data being present until diagnostics are done.

Testing

• Verify diagnostics are re-triggered when the active session changed via the console tab list view or runtime session switcher