141–150 of 213 posts
Earlier quoted context omitted.
For anyone else wondering: • LSP means Language Server Protocol [0] • ALE means Asynchronous Lint Engine [1] [0] https://microsoft.github.io/language-server-protocol/ [1] https://github.com/dense-analysis/ale
ALE is amazingly useful even for curmudgeonly old timer Vim users. My one gripe is that I want the warnings to disappear once I begin modifying the buffer, which I have achieved. Can post the relevant part of my vimrc if desired.
In my experience, the built in LSP is a mixed bag. Getting language servers configured is a breeze, diagnostics and go-to definition work just fine. But trying to get autocomplete and snippets to work is an exercise in frustration. There's a handful of different hobbyist implementations which are all somewhat-maintained and somewhat work together but it's buggy and you end up needing to do 20x the effort of using VS…
Yeah coc.nvim is a much better experience in my usage. I want to love the native LSP, but the hodgepodge of in-progress or abandoned completion, suggestion, signature, diagnostic, etc. UI is a big pain point right now. For example I have to install 3 different plugins to get all the LSP UI so it means I have 3 different opinions on how various parts of its UI should look and it's a real mess--the popups for suggestio…
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.
Is anybody else uncomfortable about the idea that an LSP client is now baked into the editor (as opposed to being a plugin)? Are there big performance gains to this approach? While LSP is great, it basically came from nowhere in the last couple of years. My concern: what if something definitively better comes along in another couple years, and we're "stuck" with this baked into the editor? For context, using ALE, I'v…
I have been an nvim user for the past few years now. I tried the whole modern nvim experience with Telescope, built in LSP and other Lua based extensions.. My conclusion is that my current setup with Ale, FZF + silver searcher, clangd/pylint and Deoplete is way faster, less buggy, albeit harder to setup. Also I'm just too old to learn the whole Lua API.. That's not something I hold against nvim, but it's a reflection…
I'd mirror your comments, and especially emphasize the speed aspect. (I think your ordering of comparisons matches the ranking of differences).
Earlier quoted context omitted.
For anyone else wondering: • LSP means Language Server Protocol [0] • ALE means Asynchronous Lint Engine [1] [0] https://microsoft.github.io/language-server-protocol/ [1] https://github.com/dense-analysis/ale
ALE is amazingly useful even for curmudgeonly old timer Vim users. My one gripe is that I want the warnings to disappear once I begin modifying the buffer, which I have achieved. Can post the relevant part of my vimrc if desired.
Neovim is great. I've moved from a very large custom vim setup to a slightly modified LunarVim [1] config (requires Neovim 0.5+), which takes full advantage of tree-sitter and LSP. Loving it so far. [1] https://github.com/ChristianChiarulli/LunarVim
I'm interested in what modifications you have made. I've been trying LunarVim a bit for the last week and am on the fence about going back to SpaceVim or just bare neovim. Not sure, still evaluating...
` vim.api.nvim_set_keymap('n', '', ':bprevious', {noremap = true, silent = true})`
to
`nnoremap :bprevious`
Why convert every single line of vimscript to a noisier lua statement?
The Packer manager seems a step back from vim-plug. Your configuration file is no longer the source of truth. Packer uses a global site directory for plugin as opposed to a local directory like vim-plug. Guess what? Neovim, paq also uses that directory. It's like the old days of plugins of installing everything globally. I had to do this after making a configuration change: :PackerSync, exit neovim, delete cache file, restart neovim, :PackerCompile. Believe me, forgetting a step has been an endless source of frustration.
Earlier quoted context omitted.
Yeah coc.nvim is a much better experience in my usage. I want to love the native LSP, but the hodgepodge of in-progress or abandoned completion, suggestion, signature, diagnostic, etc. UI is a big pain point right now. For example I have to install 3 different plugins to get all the LSP UI so it means I have 3 different opinions on how various parts of its UI should look and it's a real mess--the popups for suggestio…
Hi, neovim core member here. 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)…
Perhaps there are ways to tweak lsp_signature UI... but at this point, I chucked it all and went back to coc.nvim which does it all (suggestions, signatures, etc.) all with the same UI.
Make it like that--make it work with all UI out of the box and not make me dig through tons of plugins. That's my honest suggestion. Sorry I'm not joining a discord, etc. to give this feedback.
Earlier quoted context omitted.
Hi, neovim core member here. 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)…
I tried nvim-compe, but it explicitly doesn't support signatures (see https://github.com/hrsh7th/nvim-compe#does-not-work-function... ). So I installed the recommended lsp_signature.nvim and it's a bit of a mess. The UI for lsp_signature has enormous borders and doesn't match at all with the rest of compe. Perhaps there are ways to tweak lsp_signature UI... but at this point, I chucked it all and went back to coc.nvi…
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.
Earlier quoted context omitted.
VS Code is an awful editor in general. I don't understand how it's so popular. Maybe it's just me but I don't like having 300ms lag between every action I perform on my editor. The vim emulation is a joke. Onivim's vim emulation is great.. Because it's literally using libvim. It's also very snappy. But thats where the advantages end.
> VS Code is an awful editor in general. I don't understand how it's so popular. Maybe it's just me but I don't like having 300ms lag between every action I perform on my editor. I'm surprised to hear this take. I've been a Doom Emacs user for a while, and while it was a bit more elbow grease to get it running on OSX, it was generally worth it for the speed/flexibility... until I ran into a non-trivially large Terraf…
I'm sure at least one time spacemacs was partly to blame (aka ALL THE THINGS activated/installed) - but it's definitely a difference in "feel" where (Neo)Vim feels closer to vi, and emacs feel closer to vs code/Atom.
Earlier quoted context omitted.
lots of stuff. but mainly: * ease of getting started. nvim is just vim, you can bring over your vim config and it'll just work. * integrated lsp. you could have vscode like auto completion natively * tree-sitter. google it to believe it and much, much more
> tree-sitter. google it to believe it After Googling I have no idea what it is, it's a parser but for what? Syntax highlighting? That doesn't seem so impressive
Yes, but it enables many tools to cooperate on highlighting/"understanding" synntax.
Could someone sell me on why I should switch to this from regular Vim?