Offer an API for Output Matchers

[bollwyvl]

Elevator Pitch

original mention: https://github.com/krassowski/jupyterlab-lsp/pull/560#issuecomment-803600454

Similar to #184, offer ways for outputs (e.g. Notebook/Console rich display) to be tied to the source lines that generate them to show diagnostics, offer jump-to, and show hover information.

Motivation

When working interactively, many kinds of output (that may never never touch disk) can reference code in the document in question. A classic example is tracebacks, which are typically quite well structured for a given language. Similarly, well-known test machinery often generates canonical string outputs (e.g. pytest and jest).

Design Ideas

GitHub Actions problem matchers seem like a widely implemented and useful pattern.

Roughly:

• select an output type (probably by widget)
• use a regex (or equivalent, e.g. css, xpath) to find references to code
• emit an appropriate LSP type to a particular FeatureManager
• get back some information to help build annotations/event listeners

These could be implemented, from closest-to-user to closest-to-jupyterlab-lsp-maintainer:

• in client settings
• a language server spec, e.g. matchers: [] filled with some JSON
• dynamically generated as a mimetype in an output bundle
  • "dumb" stream checks
  • rich outputs (e.g. xunit)
• a TypeScript extension, similar to the exposed API in Expose extractor API (as separate package?) #561, e.g. IOutputMatcherManager.register(language, feature, pattern)
  • this could allow for "complex" things, but should probably be a last resort

Landing them on the Notebook first makes the most sense, but Console, Terminal, Log Viewer, and even the JSON5-based settings editor all generate well-structured outputs that we could tie back to open (or wanted to be opened) documents.