Language Server Configuration UI

Elevator Pitch

Add a per-language-server configuration system.

Motivation

Many useful properties of the language servers (and their plugins) cannot be controlled with checked-in files. This has been mentioned for pyls in specific, but other servers (like markdown) are almost unusable without deeper configuration (e.g. ignored words in spell check).

Design Ideas

Once #192 allows for fine-grained control of which server you are talking to, we can store each server’s config in a Big Untyped Blob in the lab settings, keyed by implementation name. You’d just edit it by hand in Advanced Settings. It probably makes sense to separate this from our (hopefully) well-typed config. So the advanced settings might look like:

[ ] Language Server Client    | // consult your language server for configuration options
[x] Language Servers          | {
...                           |    "pyls": {}
                              | }

I don’t think we can have (or would even want) one per server, as I don’t think there’s a way to dynamically change schema at the labextension level.

Once it’s available, it would “just” be a new message for the client to send to the proxy, and on to the server.

Maybe on the initial PR?

Once getting it working the first time, we could look at using the per-server schema to generate a UI:

We may also want to let such configuration (or humanely, collection of files, keyed by implementation name) to be checked into a repo (or put in a home dir) and found at runtime. This suggests a:

• a set of well-known locations, e.g. for pyls:

${PREFIX}/etc/jupyter/lsp/pyls.json
~/.jupyter/lsp/pyls.json
$(cwd)/.jupyter-lsp/pyls.json # could hide .virtual in here

• a lsp/config/<language-server> handler
  • merges configs from the search path?
• a new part of ILanguageServerManager that knows how to fetch it
  • merge with any stuff from jupyterlab-managed config?

[trajamsmith]

I’ve got some bandwidth to help with this, if that’s alright with you all. What’s the preferred workflow? Should I fork and branch off of master?

[bollwyvl]

In the interest of #244 and other issues, here’s a sketch of what it would take to get some kind of configurability, with the least surprising UI:

• add a JupyterLab config section (as edited with JSON in the Advanced Settings UI) to the existing plugin.json for language_servers
  • perhaps reserve the top-level object for future space, so client_settings
• when a new connection is made by the ConnectionManager, check for that language server name and send the appropriate message
• when you live edit it, send the config message

Basically everything else we can push off until later: i definitely want the ability to store this stuff someplace on the server, so it is easier to check in and share on a team, but if this answers the need on #244, and gives us the opportunity to iterate with something that works, we can make do!

I’m not sure when I’d get to this, but can certainly provide further insights.