LspInstall hates me (no pyls)

[mcepl]

So, when you removed lsp#add_filetype_config() and made the general configuration impossible to use (and removed all examples from :he lsp.txt), I admit defeat and I pull in this plugin to the so-called “built-in” LSP client.

What should I do? Right, there is that awesome :LspInstall command:

:LspInstall
LspInstall      LspInstallInfo
:LspInstall    
tsserver  bashls    cssls     elmls
:LspInstall

OK, no luck with pyls (because of course bashls is a way more important than what just some mere Python programmers need). But, wait! There is lua/nvim_lsp/pyls.lua, so perhaps not all hope is lost. Adding

call nvim_lsp#setup("pyls", {})

to my $VIMRC and … it actually works! OK, I guess, thank you.

So, the only complaint in this ticket is that :LspInstall is useless for me (and a small sob that it is not possible to configure the client manually anymore; oh well).

[bfredl]

because of course bashls is a way more important than what just some mere Python programmers need

@mcepl This is not how open source works. This just means someone cared enough about bashls to contribute the code already. If pyls in LspInstall is important to you, you are free to make a PR for it :)

[mcepl]

because of course bashls is a way more important than what just some mere Python programmers need

@mcepl This is not how open source works. This just means someone cared enough about bashls to contribute the code already. If pyls in LspInstall is important to you, you are free to make a PR for it :)

Sure, I was just suprised that LspInstall was not able to find “pyls” configuration, when the plugin is there, but yes, I admit, I am too lazy to debug it properly. But malfunctioning LspInstall is just a nit, I have been much more disappointed by removing perfectly working configuration method and replacing it with something so complex and baroque that mere humans are not able to do it and we need this repository at all.

[clason]

@mcepl LspInstall is a convenience function to install the server (binary) from neovim in case it is not installed already. Since pyls is just a pip away (and messing with venv is iffy), this was not a high priority. If the server is already installed in your system (say, using zypper), call nvim_lsp#setup("pyls", {}) is indeed the correct and suggested way of enabling it, as is clearly stated in the README (and if it is not, feel free to suggest specific improvements there).

(And some expectation management is in order: the neovim LSP -- and this support repository -- is not yet meant to be ready for production use; this repo is meant as a) a showcase and b) a place for masochists intrepid early adopters to contribute code to.)

[bfredl]

it with something so complex and baroque that mere humans are not able to do it and we need this repository at all.

@mcepl But the reason nvim-lsp is more complex is that supporting all these servers is intrinsically complex. By your own definition, vscode doesn't have “built-in LSP", because many servers expect you to install a vscode-LANG plugin which configures the server properly. The only difference is that we are bundling all these configs with in a single plugin/repo.

Also please be a bit patient, the config implementation won't be finished until Nvim 0.5 is released. This repo exists so that nvim master + this-repo master yields a somewhat stable/usable config. Chances are we will ship config for common serves into Nvim 0.5 release itself, when it is time :)

[mcepl]

@mcepl But the reason nvim-lsp is more complex is that supporting all these servers is intrinsically complex.

Well, I used to have this in my $VIMRC:

call lsp#add_filetype_config({
    \ 'filetype': 'python',
    \ 'name': 'pyls',
    \ 'cmd': [ 'pyls',  '--log-file', '/tmp/pyls-log.txt']
    \ })

(even with some optional paramters) and it worked pretty fine. Now I would have to apparently put basically whole https://github.com/neovim/nvim-lsp/blob/master/lua/nvim_lsp/skeleton.lua in my $VIMRC. How else should I call it than worsening of the situation?

B y your own definition, vscode doesn't have “built-in LSP", because many servers expect you to install a vscode-LANG plugin which configures the server properly.

If you are measuring neovim with the monstrosity like VSCode, you lost. Is that your ideal? Really? And yes, apparent inability of VSCode even to work with a generic LSP server (and whole disaster of MS Python LSP server) doesn’t make me looking up to VSCode as my hero.

A lso please be a bit patient, the config implementation won't be finished until Nvim 0.5 is released. This repo exists so that nvim master + this-repo master yields a somewhat stable/usable config. Chances are we will ship config for common serves into Nvim 0.5 release itself, when it is time :)

And why not doing it right now and merge this repo into neovim repo immediately and develop it there?

[norcalli]

@mcepl I also remember you as the person who repeatedly complained about completion not working, and yet you haven't even attempted to help me with implementing it. Just in case you're not aware, this entire repo (save for a few PRs which I'm very thankful for) and all of the LSP work is being done by exactly 1 person, which is me.

By virtue of creating this issue, you must have updated master last night, which means you are on the bleeding edge of bleeding edges, and yet you seem to expect stability, which is quite insane. If you aren't interested in contributing, then I suggest not pursuing this line of questioning further, because using the LSP right now isn't for you then.

[bfredl]

If you are measuring neovim with the monstrosity like VSCode, you lost. Is that your ideal? Really? And yes, apparent inability of VSCode even to work with a generic LSP server (and whole disaster of MS Python LSP server) doesn’t make me looking up to VSCode as my hero.

But LSP is "vscode remote plugin" but moderately changed/improved to be editor general protocol. I am afraid we cannot undo reality (maybe we can make our own protocol, soon...). making things magically work for any server without code for that server is not our ideal, because it is not possible.

And why not doing it right now and merge this repo into neovim repo immediately and develop it there?

you can create this effect yourself already by keeping both repos in sync, like you do now

[mcepl]

@mcepl I also remember you as the person who repeatedly complained about completion not working, and yet you haven't even attempted to help me with implementing it. Just in case you're not aware, this entire repo (save for a few PRs which I'm very thankful for) and all of the LSP work is being done by exactly 1 person, which is me.

I am perfectly aware (and very thankful) that you are the person who finally made LSP pull request merged.

Is reporting a bug suddenly “complaining”? I have mentioned the issue in https://github.com/neovim/neovim/issues/11389 just so it is not forgotten, but I have tried never to bother you about it.

Perhaps in this situation I was complaining that something which worked doesn’t work anymore. Yes, you are right, I should either fix it or I should (more likely) just shut up.

And you are right, this conversation is not productive. Let’s finish it here.