Implement console log window messages, update lsp-ws-connection

[krassowski]

References

Fixes #601 and updates lsp-ws-connection:

Code changes

• use import type if possible
• update:
  • "vscode-jsonrpc": "^6.0.0",
  • "vscode-languageserver-protocol": "^3.16.0",
  • "vscode-languageserver-types": "^3.16.0",
  • "vscode-ws-jsonrpc": "0.2.0"
• remove unused code from lsp-ws-connection
• deprecate the emit() and getter based API for lsp-ws-connection
• add new API with well-typed:

  public serverNotifications: ServerNotifications;
  public clientNotifications: ClientNotifications;
  public clientRequests: ClientRequests;
  public serverRequests: ServerRequests;

User-facing changes

Backwards-incompatible changes

Chores

• linted
• tested
• documented
• changelog entry

[krassowski]

CC @bollwyvl . I know this is a different pattern from the existing one, but trying to experiment on doing it better. I also know the dream would be to generate typings from a JSON file; the handlers for signals could be also generated from JSON, but not sure if those would work for all handlers + some signals might be performance-critical and maybe using direct callbacks rather than lumino Signal could be better.

[bollwyvl]

Welp, even lower in the stack is the lumino Message bus. Nobody talks about it much, but it is extremely robust, and what makes all the core widget stuff very smooth.

But performance-critical is as performance-critical-is-measured... we'd need some no-fooling benchmarks before stepping too far off something that at least quacks likes other parts of the stack.

[krassowski]

Cherry-picked from #278 but Methods now grouped into enums for run-time generation of signals and handlers, CC @bollwyvl

[bollwyvl]

Cool! Someday we'll be able to close that one out! Over in jupyter_server meeting, we talked about some approaches for moving forward for improving reuse of specs as docs (yay) and simple type packages (no ORMs, future-imperiled pydantic stuff, etc).

I don't know how this would work out here, as these are sometimes a good deal more complicated.

[krassowski]

The idea is to have strong separation between server/client, notification/request as otherwise those get mixed up. Also, this implementation does not require manual typing anymore. Eventually I would like to define an interface of ILSPCompletion (as you did in #278) and make everything else an implementation detail. I hope that this would allow to smoothly add the kernel approach from #278 too (as an alternative implementation of the interface).

[bollwyvl]

Yeah, well... the upstream LSP spec hides that particular piece of information (whether a message is in a request or a notification) behind some emoji. In the various attempts at building schema for it, I had to parse that business and build actual models of the exchange sequences: not so much fun.

In the jupyter_server discussion, the idea was to get to where we can incrementally define robust, declarative, language-agnostic specs (JSON Schema, OpenAPI, AsyncAPI, kaitaistruct) for different parts of the architecture, from which many language "bindings" could be built, as close to the standard library of that language as possible. Unfortunately, the place I called out initially was the ContentsManager API... which would drag along nbformat, and a subset of kernelspec. From there, the kernel session REST, and eventually the kernel interchange itself, could be documented... that would either be the baseline for the LSP Comm approach, or at least give us enough ground to stand on to document our "special" websocket.

Semi-related, if kernels were better able to describe, and report, their special syntaxes, and ideally a syntax highlighting approach... well, that sure would make a composite language document more understandable, and a lot easier than ginning up custom typescript extensions.

More concretely here... I think really supporting multiple sources (of any of these things) will end up needing a more explicit document/mark model, a la #500... in the case of a completion, documentation requests, etc. these would be extremely short-lived, but one should see whatever is available as fast as possible, but know that some other sources might be coming, and be able to configure the hell out of them, e.g.

In []: df.<TAB>
       |----------------------------------------|
       | apply                            [lsp] |
       | some_col                         [jkm] |
       |----------------------------------------|
       | Sources [lsp] 300ms  [jkm] 100ms [gear]|