search

sublimelsp / lsp_utils

Module with LSP-related utilities for Sublime Text
https://sublimelsp.github.io/lsp_utils/
MIT License
16 stars 6 forks source link

Create separate handler for the new LSP API #14

Closed rchl closed 4 years ago

rchl commented 4 years ago

Use the new API in ST4. Technically nothing should change for existing plugins but it will allow them to use new features like access to Session.

It's still using ServerNpmResource for installing dependency rather than using only new API as new API is not async yet so it would provide worse experience.

rchl commented 4 years ago

Actually one thing might change. Since this no longer passed "scopes" and "syntaxes" it doesn't trigger warnings but that also means that LSP-intelephense might not use equivalent selector now.

rchl commented 4 years ago

No wait, I still pass everything. I guess I just had that in my plans but didn't do.

rchl commented 4 years ago

"An author of a plugin LSP-xyz has a setting file Helo.sublime-settings in which he store the server configuration. Where does the author need to make a change to load the Helo.sublime-settings instead of the default LSP-xyz.sublime-settings which the NpmClientHandler assumes?". Right now I don't know the answer. (this is what I mean, by not explicit)

Ideally, the author will follow the convention and name the settings file the same as the package name. If the author wants to break out of that, it's still possible but then has to override configuration() and implement settings reading himself.

Also now we have NpmClientHandler(v2 used for ST4) that extends the Abstract Plugin, And one NpmClientHandler(v1 used for ST3) that extends the LanguageHandler. I honestly don't know where is what anymore.(but that is my problem) :)

At least plugin authors shouldn't need to know the internal details as NpmClientHandler has the same API for both ST3 and 4.

For us, working on lsp_utils, it's more complicated yes, but that's the price we have to pay for keeping compatibility with ST3. Otherwise, the packages would just be changed to use the new LSP API directly (maybe with some help from ServerNpmResource) and things would be simpler.

Also, the fact that the new LSP API is more complex is what allows us to be more flexible. So there is a balance we need to keep somehow.

rwols commented 4 years ago

The complexity stems from the fact that lsp_utils needs to support two api versions. I have a somewhat working LSP-palantir-pyls package that is very straightforward. I’ll upload it soon.