I'm definitely stealing this hack, what a great way to filter for high potential people.
150 karma · joined February 20, 2021
You'll have to define slower (time to diagnostics, time to completion, are you really talking about the performance of nvim-cmp instead, etc.) preferably in a bug report with benchmarks. I've done several rounds of performance optimization since 0.5, and I haven't heard any complaints since 0.6 when I swapped out our json decoder.
You'll have to file a bug report, because none of the built-in LSP stuff should cause any performance degradation.
> syntax highlighting just stops working randomly
This has nothing to do with LSP.
> files get spewn all over my repositories that I have to .git/info/exclude
Neovim does not automatically create files in your repositories.
Lspconfig currently has 3 parts, the default settings for the servers, an implicit project detector to trigger when to launch the servers (conditioned on filetypes and some patterns), and the infrastructure to manage launching/shutting down/attaching buffers to servers as you open files within the same project.
Eventually we'd like parts 2 & 3 to be in core as a "projects" module, leaving separate "project patterns" and "server settings" as mostly metadata containing repositories.
That would open the door for third party plugins to create customized project templates which map keybindings, set formatexpr, pass custom server settings, etc. similar to how coc.nvim has coc-pyright, coc-gopls, etc. These plugins could also handle installing language servers automatically should they choose to offer that.
There's also nvim-lsp-installer, but I really don't like the approach it takes of hijacking lspconfig's setup.
Source? We have an extremely extensive test suite for the built-in client that must pass for every merge, and we currently have ~30 open issues on the issue tracker (with a good chunk of those being feature requests).
This is fine in the nvim-cmp world, there's a config example in the lspconfig wiki, it's about 5 lines for the integration. The recommended lspconfig configuration (included snippets and autocompletion) has less lines of code than the example in the readme for coc.
> formatting
This is built-in to neovim's LS client (vim.lsp.buf.formatting()), adding an external formatter can be done with formatexpr (built-in)
Any issues with the language server I doubt are client side, and every request/response is "async".
For a minimum setup it is:
1. Install the language server via opam:
opam pin add ocaml-lsp-server https://github.com/ocaml/ocaml-lsp.git
opam install ocaml-lsp-server
3. Add the following to your init.lua
require'lspconfig'.ocamllsp.setup{}
We're not trying to target vscode users, so if the above is too many steps that is ok, you just aren't our target audience.
Anything done on the language server side is already coc/built-in client agnostic (since communication is done over json-rpc, except for tsserver which MS has not yet exposed via the LSP, so we rely on the typescript-language-server-wrapper), anything on the client side is marginally useful at best.
https://paste.sr.ht/~mjlbach/1a1df5cd61627e87ea4c4355a0473bf...
These are just my top 5.
* vim.diagnostic (see gpanders talk at https://www.twitch.tv/videos/1220189913?t=00h58m27s)
* vim.json (api-fast safe json deserialization with vendored lua-cjson)
* virtual lines (https://github.com/neovim/neovim/pull/15351)
* lua bindings to xdiff (https://github.com/neovim/neovim/pull/14536)
* a million bugfixes as you say :)
I personally worked on fixing utf handling around the built-in language server client, rewriting the incremental sync algorithm, vim.json (the built-in language server client is now fine with typescript-language-server thanks to the deserialization improvements), amongst various other small improvements.
Note, I use sway but don't notice much of a battery difference on gnome or plasma.
The only thing that pops up by default right now is diagnostics.
We provide a client, not language servers, so we're kinda at the mercy of whatever language servers exist. We offer a configuration in lspconfig for https://github.com/theia-ide/typescript-language-server which wraps tsserver, but there is hope that microsoft could implement lsp protocol directly for tsserver https://github.com/microsoft/TypeScript/issues/39459#issueco... at which point the experience should be more comparable to coc.nvim.
On a different note, we have made upstream requests to MS, worked with language server authors, and generally try to contribute positively to the language server ecosystem. Neovim users will always be free to use coc.
If you have actionable items for improving the client, please reach out on our discourse or on our matrix channel. Thanks!
Many of our users explicitly don't want automatically called functions that would slow down the editor (autocommands that map signature requests to the language server, for example), so by nature neovim's core implementation is extremely conservative.
One thing I would like to do, is make the automatic pop-ups for signature easier to implement with our current handler, which means a plugin like signature-x could use our upcoming lsp.config option to configure it's borders (https://github.com/neovim/neovim/pull/14681), and match the rest of the UI.
I also have another project I was working on before the 0.5 stabilization phase (https://github.com/mjlbach/neovim-ui). The goal with this is to have composable/overridable UI elements built into core (which we would use for our internal lsp functions), that can be used (or overridden) by UI plugins.
In summary, I think the likelihood of autocompletion (and generally auto-anything) being built-into core is very small, but providing the APIs in neovim core to make snippets - autocompletion - automated UI elements easier for plugin authors is a high priority.
Which UI plugins do you need? We've done a lot of work leading up to 0.5 in improving the built-in handlers, so you shouldn't need a UI plugin. I think the main plugins people install (in addition to lspconfig):
* nvim-compe (autocompletion)
* vim-vsnip (snippets)
* lsp_signature.nvim (automatically pop up signature window, note signature_help is built-into core, just manually triggered)
Some people use lspsaga.nvim, but borders are already merged into the core handlers (and our floating windows now provide better markdown styling than lspsaga), so the main utility of lspsaga is in the different way of interacting with code actions, which I personally do not prefer.
Anyways, please open an issue or PR if you have concrete suggestions (or start a discussion on our discourse)! I'm personally very invested in improving the UX around the built-in language server client, and it has really improved leading up to the 0.5 release.
Neovim has already integrated many of the "obvious defaults" (see :help nvim-defaults), but if you're a user and feel that something is missed you should file an issue.
I personally don't mind that the defaults may not be what I'd like, as once they are set, I spend very little time modifying my system configuration. I realize this can be a barrier to new users though.
- 34 lines to set up plugin manager/install plugins
- 43 for keybinds
- 35 for documentation
- 50 for autocompletion
- 20 for customizing one language server for plugin development (sumneko)
It adds up for sure, and neovim/vim/emacs are not ever likely going to be as plug & play as vscode/intellij, but I would argue the target user for vim/neovim/emacs is someone who wants more customization, which is almost always going to mean the configuration is more verbose.
If you have concrete suggestions on cutting down this config in particular, you can file an issue/PR. The main reason I created this, was because we (core neovim team) get a lot of "I just want something that works" type feedback (which to many includes autocompletion and default keybinds, which are almost 1/3 of the config)