Language Server Configuration UI

bollwyvl commented 4 years ago

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?

krassowski commented 4 years ago

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

Yes!

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: [...]

I would be very careful about this, especially using the well-known locations... Sounds high-maintenance.

bollwyvl commented 4 years ago

Re: config on server: for context, my motivating use case around all of this is about aligning a team in hub+lab+lsp to get some work done:

if a team is shipping some software, they need to embody their code style guide in their tooling to avoid review/ci nitpicking
if a team is writing a paper across many notebooks, they need one file that contains all the spell check exceptions for the field of study to avoid extra draft cycles

Since some of these things can't be configured as files checked into vcs and found by the running process, I need... something.

Simpler than bespoke dedicated files would be more stuff in jupyter_notebook_config.d. I'm hesitant to hang it directly off the language_servers spec, because it won't be validateable and is important (unlike the config_schema, which would be unvalidateable but only best-effort for UI), so it should probably be a new traitlet, e.g.

$(cwd)/jupyter_notebook_config.d/pyls.json

{"LanguageServerManager": { "language_server_configs": { "pyls": {} } }}

This makes three extra layers of JSON nesting, but would give us a lot of functionality with less maintenance risk.

On Thu, Feb 13, 2020, 09:38 Michał Krassowski notifications@github.com wrote:

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

Yes!

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: [...]

I would be very careful about this, especially using the well-known locations... Sounds high-maintenance.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/krassowski/jupyterlab-lsp/issues/196?email_source=notifications&email_token=AAALCRE2TZGZL4MLCM54SK3RCVLNXA5CNFSM4KUTIDP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELVGMHA#issuecomment-585786908, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALCRHQCUSFSGSAR7IDDG3RCVLNXANCNFSM4KUTIDPQ .

bollwyvl commented 4 years ago

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.

trajamsmith commented 4 years ago

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?

krassowski commented 4 years ago

Yes, please go ahead. Feel free to make an early WIP PR, as this will trigger the CI builds along the way and enable early feedback/help from our side.

bollwyvl commented 4 years ago

Sounds great. Of course let us know if any of the contributing stuff is unclear.

If we're agreed on using the lab settings manager, a good place for us to help is to build up the sketch of the acceptance test. We can just hack it in directly to your or, once started.

The simplest place to test this would be an editor test of just the yaml server you care about... Then we extend it in subsequent prs for pyls (has open issue, don't know number off-hand) and markdown.

For yaml, the basic flow will probably be something like:

open a fixture yaml file with a schema error and a yaml error (duplicate keys)
wait for initialized
see only one diagnostic
open advanced settings
change settings Json, "commit"
see two diagnostics

On the other servers we'll want the opposite (see diagnostics, reconfigure, don't see as many diagnostics) which might impact the eventual keywords, but simple is better!

Good luck!

On Wed, Apr 15, 2020, 10:55 Michał Krassowski notifications@github.com wrote:

Yes, please go ahead. Feel free to make an early WIP PR, as this will trigger the CI builds along the way and enable early feedback/help from our side.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/krassowski/jupyterlab-lsp/issues/196#issuecomment-614088774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALCRAZJS2MXQELXRMZSXTRMXDEVANCNFSM4KUTIDPQ .

bollwyvl commented 4 years ago

So the next stage of this is actually bringing in a ui component that knows how to draw schema. Best I can offer right now is jupyterlab-rjsf (npm) based on react-jsonschema-form. The docs are a bit scarce on integrating the jlab thing, but having used it in a few places, I'm confident I can get it up and running.

As to what it actually looks like: would :heart: some thoughts. There are no hooks in the Lab settings page to add more views, alas (maybe that's a better upstream PR than just trying to ram rjsf in for all the settings, but i digress). So we'd need to have another dedicated panel.

split panel with
- List of language servers (maybe grouped by status)
- the currently-selected server
- some more metadata (site, etc.)
- config form, save/cancel buttons
- log?

Rough sketch:

 ___________________
| Language Severs  x|_______________________________________________
| RUNNING                   |
|                           |  [pyls](https:/..)                                       
| # pyls                [x] |  
|                           |  CONFIGURATION
| AVAILABLE                 |  
|                           |  pyls.configurationSources
|   bash-language-server    |  
|   ...                     |  > List of configuration sources to use.
|   yaml-language-server    |    [-] pycodestyle
|                           |    [+]
|                           |________________________________________
|                           |  [SAVE]  [CANCEL]  [RESET]

jupyter-lsp / jupyterlab-lsp