Our great sponsors
-
-
coc.nvim
Nodejs extension host for vim & neovim, load extensions like VSCode and host language servers.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
distant.nvim
🚧 (Alpha stage software) Edit files, run programs, and work with LSP on a remote machine from the comfort of your local environment 🚧
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
While not exactly an omni trigger, I think that adding an omni completion flag to ':h complete' could be a great minimal addition. Setting something like setlocal complete=o for lsp buffers could be great for people who prefer using omnifunc, but hate typing c-x c-o. I have opened an issue related to this here.
I would recommend you to not cover up for 3 by yourself and instead do like pointed here, in the "Direct" case. A server that supports workspaces, but doesn't at least gracefully acknowledge null, and instead actually silently misbehave on it, is simply nonconforming, because null is a way any client implementation can pick to communicate no workspace have been configured, as permitted by spec, so it shouldn't lead into silent misbehavior. It's responsibility of server authors to cope with this, and if they don't, then users should be made very aware of that by means of "requireRootPattern == true" / interactive-root-picker, which builds pressure for things to get fixed where they should.
https://github.com/neovim/nvim-lspconfig/issues/1028 (not a single mention here, besides my late own, and I got a heart here!, but it has been muted)
If this is the case, I'm not sure a user should be using neovim, because they are likely to be unsatisfied generally with the customization experience which going forward will require more and more lua. I think efforts like https://github.com/phaazon/poesie.nvim may help address this by adding a declarative plugin configuration layer in something like json which could be "set" by a GUI. I've been talking to phaazon how to move that effort forward.
haha nw, I'm actually planning on working on something semi-related. For now you should check out https://github.com/chipsenkbeil/distant.nvim which does something similar, albeit closer to how vscode does it (remote daemon)
Just as a reminder, lspconfig is one "front matter" to the client, the built-in client is usable without it, but I think it's more helpful to think of it as an API. That means comments like "make it easier to use", "add autocompletion", "make it install servers automatically" is not a neovim/neovim issue and not what this thread is for discussing. I made a proof-of-concept of a meta-package that bundles everything together (yes, it's a joke, but it does actually work) that someone can run with.
So I am not sure if this is related, or it might even exist already. But it would be cool to have an auto import api for plugins. I made an issue in LuaSnip about this a week ago, https://github.com/L3MON4D3/LuaSnip/issues/195
Just want to say I looked into this again tonight. I filed an issue with omnisharp: https://github.com/OmniSharp/omnisharp-roslyn/issues/2250
To cover them up because you know they're not following the spec, while they in fact could (incorrect/incomplete implementation).