171–180 of 213 posts
One little-talked about advantage of Lua support is that you can now write your vim config/scripts in one of the various Lua transpilers like moonscript [0], or maybe even typescript [1]! [0]: https://github.com/leafo/moonscript [1]: https://github.com/TypeScriptToLua/TypeScriptToLua [2]: https://github.com/hengestone/lua-languages
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…
Agreed. It took me half a day and I came not remotely to the UX and performance of coc.vim. Most incl. the nvim team are not aware that eg. tsserver is the fastest and most responsive code formatter for TS (yes, it goes beyond the LSP spec but that's how it is, also for historical reasons). Prettier does not come close. Maybe they've never tried or deliberately ignore coc.vim for whatever reason. coc.vim works almost…
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!
Earlier quoted context omitted.
I understand the frustration (making neovim more cohesive is definitely a goal). It sounds like coc provides the UI you are used to, so there's no harm in sticking with that! 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 conserv…
If we're just spitballing thoughts, I'd like something that's kind of the opposite of zen mode. I don't always want signatures and completions and things binging and bopping and showing me suggestions--if I'm working on a codebase and language I'm fluent in then all of that gets turned off. But if I have to pick up some under-documented massive codebase where everyone just uses VS code/intellisense--I'm going to need…
The only thing that pops up by default right now is diagnostics.
Could someone sell me on why I should switch to this from regular Vim?
Integrated LSP is quite nice (and the ecosystem around it is just getting started), but it’s not the thing I’m most excited about. My favourite new thing is actually tree-sitter. Currently it’s being hyped for better syntax highlighting (which is nice), but I’m most excited about defining text objects on language constructs. I really don’t like trying to shoehorn words, sentences and paragraphs to deal with parameter…
This plugin sets it all up and has some examples: https://github.com/nvim-treesitter/nvim-treesitter-textobjec...
There is a middle ground for VS Code users: https://github.com/asvetliakov/vscode-neovim This extension integrates neovim into the VS Code environment by mapping keystrokes from VS Code to the neovim binary. This approach (which requires 0.5) is much simpler and more robust than attempting to emulate all of VIM, as the VSCodeVIM extension does.
I've always scratched my head at this plugin. Is the idea that you have both a VS code configuration for all the stuff around the editor (themes, UI stuff, all kinds of fancy VS code features like its file tree, git tree, testing, etc.), and a neovim configuration for the editor component itself? How do language servers and such work--are all the slick one click VS code installed extensions ignored and you're back to…
Earlier quoted context omitted.
LunarVim has a "show b̶u̶f̶f̶e̶r̶s̶ registers" plugin enabled so when you type " it brings up a window showing the contents of various buffers, so you can eyeball it rather than remembering.
https://github.com/junegunn/vim-peekaboo
https://github.com/neovim/nvim-lspconfig#keybindings-and-com...
dwarfs my .vimrc
Could someone sell me on why I should switch to this from regular Vim?
Nice work! One small piece of feedback. Maybe I'm alone in this but I'd to see default keybinds and config for LSP. I like to keep my config small and defaultly and this: https://github.com/neovim/nvim-lspconfig#keybindings-and-com... dwarfs my .vimrc
For complex things, it's nice to be able to do this. But the benefit of having a built-in client is that it works out of the box. This looks like it requires more configuration than many of the existing (n)vim lsp clients, even for the most basic thing: setting up the keybindings.
Earlier quoted context omitted.
Regarding programming languages, the answer is the language server protocol (LSP), an editor-agnostic way to use IDE-like features, originally developed for VSCode. Works for both Neovim and VSCode (and many others). Somewhat ironic that one of VSCode's best inventions is the one which made me switch away from it.
I saw it as Microsoft's signalling that they care more about being in the good graces of the wider developer community than about dominating the programming editor/IDE market. After all VSCode is free. I'd argue that giving away VSCode, LSP, Monaco (the base editor) and so on has been a successful means of redeeming their brand in the eyes of developers and really anyone who ever touches code. That could backfire if…
They've done it before and they'll do it again.
LSP for MS and VS Code is "come, make our proprietary editor more valuable by supporting languages we can't be arsed to worry about!"
https://github.com/microsoft/pylance-release/issues/4
(I am an enthusiastic advocate for LSP otherwise.)