Enhance language server spec #89
Labels
enhancement
New feature or request
Comments
|
It's probably also worth generating some documentation from the schema: |
|
+1 for more readable (markdown) schema docs. As for the UI/UX feedback and in regard to the design proposed in https://github.com/krassowski/jupyterlab-lsp/issues/85#issuecomment-549745289 the only thing I have a problem with right now is to group connections by the server. This is usually an easy task, but the problem comes in when there is more than one LSP server supporting the same language:
where server1 is specialized in JS and takes precedence over server2 in handling JS, even though both support JS. Just a hypothetical situation I want to ponder right now so we are prepared for the future. Does it make sense? |
|
Yeah, there are a number of challenges.
There's no reason we can't push the configuration key forward, I was just
avoiding it until necessary because they are often super long, and the
languages are what people care about, i'd wager. But you're very right.
To that end, I think it's inevitable that we will end up with users wanting
multiple servers for a particular language in the same document, and
there's no way to tell which server is answering with the current
language-based endpoint scheme, nor does lsp offer a place to put it. If
the client trusts the notebook server for language info, as it does for
kernels, there's no reason not to have one socket per language _server_,
and it will advertise to the client what file extensions, mime types, etc.
it supports. This would normalize a lot of things.
The client would _still_ get a menu of all the languages available, so it
could take over new complexity in joining diagnostics from different
servers.
I don't think this is an appropriate place to be hacking stuff into
messages, nor do I feel we should add an "envelope" that does not conform
to lsp, even though it would make it more jupyter-like, since we just don't
have enough data (e.g diagnostics Just Happen).
…On Tue, Nov 5, 2019, 04:57 M. Krassowski ***@***.***> wrote:
+1 for more readable (markdown) schema docs.
As for the UI/UX feedback and in regard to the design proposed in #85
(comment)
<https://github.com/krassowski/jupyterlab-lsp/issues/85#issuecomment-549745289>
the only thing I have a problem with right now is to group connections by
the server. This is usually an easy task, but the problem comes in when
there is more than one LSP server supporting the same language:
1. will this ever be the case that we will have two LSP servers for a
language? I guess it's likely once users start to experiment
2. How we can identify the LSP server in use by a particular
connection? Probably comparing the endpoint address of the connection and
the endpoint assigned by the server extension would make sense (even if two
servers provide a language, there is only one in use at a time, and it is
the one which handles the endpoint, right?) - in that case we would like to
have the endpoint names which redirected to a particular server available
in the sessions response; something like:
[
{
"display_name": "Server 1",
"languages": ["javascript"],
"endpoints": ["javascript"]
},
{
"display_name":": "Server 2",
"languages": ["javascript", "typescript"],
"endpoints": ["typescript"]
}
]
where server1 is specialized in JS and takes precedence over server2 in
handling JS, even though both support JS. Just a hypothetical situation I
want to ponder right now so we are prepared for the future. Does it make
sense?
—
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/89?email_source=notifications&email_token=AAALCRGRCH7TRTOFSEBZWODQSE7SPA5CNFSM4JHVUCOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDCIQBY#issuecomment-549750791>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALCRGXRQNZBLUNHITUKBLQSE7SPANCNFSM4JHVUCOA>
.
|
|
Oh and all the sessions that can answer a language are running all at once,
and will get all messages from all clients. We should add a second server
for some languages to see what the behavior is.
…On Tue, Nov 5, 2019, 07:03 Nicholas Bollweg ***@***.***> wrote:
Yeah, there are a number of challenges.
There's no reason we can't push the configuration key forward, I was just
avoiding it until necessary because they are often super long, and the
languages are what people care about, i'd wager. But you're very right.
To that end, I think it's inevitable that we will end up with users
wanting multiple servers for a particular language in the same document,
and there's no way to tell which server is answering with the current
language-based endpoint scheme, nor does lsp offer a place to put it. If
the client trusts the notebook server for language info, as it does for
kernels, there's no reason not to have one socket per language _server_,
and it will advertise to the client what file extensions, mime types, etc.
it supports. This would normalize a lot of things.
The client would _still_ get a menu of all the languages available, so it
could take over new complexity in joining diagnostics from different
servers.
I don't think this is an appropriate place to be hacking stuff into
messages, nor do I feel we should add an "envelope" that does not conform
to lsp, even though it would make it more jupyter-like, since we just don't
have enough data (e.g diagnostics Just Happen).
On Tue, Nov 5, 2019, 04:57 M. Krassowski ***@***.***> wrote:
> +1 for more readable (markdown) schema docs.
>
> As for the UI/UX feedback and in regard to the design proposed in #85
> (comment)
> <https://github.com/krassowski/jupyterlab-lsp/issues/85#issuecomment-549745289>
> the only thing I have a problem with right now is to group connections by
> the server. This is usually an easy task, but the problem comes in when
> there is more than one LSP server supporting the same language:
>
> 1. will this ever be the case that we will have two LSP servers for a
> language? I guess it's likely once users start to experiment
> 2. How we can identify the LSP server in use by a particular
> connection? Probably comparing the endpoint address of the connection and
> the endpoint assigned by the server extension would make sense (even if two
> servers provide a language, there is only one in use at a time, and it is
> the one which handles the endpoint, right?) - in that case we would like to
> have the endpoint names which redirected to a particular server available
> in the sessions response; something like:
>
> [
> {
> "display_name": "Server 1",
> "languages": ["javascript"],
> "endpoints": ["javascript"]
> },
> {
> "display_name":": "Server 2",
> "languages": ["javascript", "typescript"],
> "endpoints": ["typescript"]
> }
> ]
>
> where server1 is specialized in JS and takes precedence over server2 in
> handling JS, even though both support JS. Just a hypothetical situation I
> want to ponder right now so we are prepared for the future. Does it make
> sense?
>
> —
> 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/89?email_source=notifications&email_token=AAALCRGRCH7TRTOFSEBZWODQSE7SPA5CNFSM4JHVUCOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDCIQBY#issuecomment-549750791>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAALCRGXRQNZBLUNHITUKBLQSE7SPANCNFSM4JHVUCOA>
> .
>
|
so we are heading towards |
|
I would imagine
/lsp/server/pyls
There's no point to having the trailing python, as a single running server
can handle multiple languages under the same process, to my understanding.
…On Tue, Nov 5, 2019, 17:52 M. Krassowski ***@***.***> wrote:
there's no reason not to have one socket per language *server*,
and it will advertise to the client what file extensions, mime types, etc.
it supports. This would normalize a lot of things.
so we are heading towards /lsp/<server>/<language> as in /lsp/plys/python
for the next spec version?
—
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/89?email_source=notifications&email_token=AAALCRGZLOSFM6MMTVOXAJ3QSH2JZA5CNFSM4JHVUCOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDET4WA#issuecomment-550059608>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALCRALDINJZZMXN5CTLGLQSH2JZANCNFSM4JHVUCOA>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For https://github.com/krassowski/jupyterlab-lsp/pull/81#issuecomment-548042214
The current spec is a little limited as revealed in #81 for really driving UI. A more complete spec might be something like (not suggesting YAML, just easier to write):
This would necessitate a bump to the
entry_pointspec version, e.g.jupyter_lsp_spec_v1, though it may be possible to maintain backwards compatibility...The text was updated successfully, but these errors were encountered: