Neovim 0.7 Released
github.com
github.com
> BREAKING CHANGES
> Support for Python 2 is dropped. For Python 3, the minimum supported version is 3.6. Legacy :pythonx commands are still available, and always uses the python 3 provider.
The client-server part is the one I'm most excited about. It is one of my favorite things in kakoune and it'll be nice to have it on neovim too. I find it more intuitive to use separate terminal windows with all the usual window manager shortcuts, instead of using vim-specific terminal splits.
I recently came across the which-key.nvim (https://github.com/folke/which-key.nvim) neovim plugin, which helped me a lot to speed up finding what movement I want to do. It basically shows you a popup with what combinations are possible after you press any key (while nvim waits for the next one), so you can basically explore commands by just pressing keys, instead of having to look them up.
I think this would have sped me up even more. Definietly neat. There's also a few plugins/configs around highlight as-you-search worth exploring. That being said I strongly recommend against going plugin shopping, you only need precious few. It is a better use of your time to do it the hard way sometimes.
Seems odd to not mention how to do this in init.lua
vim.g.<var> = <val>Does the new filetype.lua script still run the ftdetect/ scripts? Or will those only be run by the filetype.vim fallback and need to be ported to the new system?
Hmm, if I type "git commit" within the terminal, is there some value of $EDITOR that would make it launch a buffer to edit the commit message, then finish when I close the buffer? (and if so, are there distinguishable success vs failure ways to close the buffer?) That's my biggest editor-within-an-editor moment.
Alternatively, Tim Pope's fugitive is pretty great and you can write :Git commit and it does just that.
That said, this sort of remote opening has been possible in Neovim since the client-server stuff was added in the early days. This is only adding the remote editing flags and implementation to Neovim itself to make it easier.
Neovim-remote(https://github.com/mhinz/neovim-remote#typical-use-cases) is an outside-of-Neovim way to do it with the Python client. It has an $EDITOR setting listed there. Or if you don't want to use Python, you can use invim(https://github.com/groves/invim#to-use-as-your-git-commit-me...). It's just a shell script. Or you can wait for the next release!
So I get 98-100% of what an IDE gives me, I can use my editor over ssh and edit anywhere, I don't need a GUI to even be installed on the system where I have all of my cores and RAM for compiling the kernel, it starts up instantly, and it's completely free and open source, not driven by a corporation, and there's decades of documentation on how to use it.
Edit:
I really don't understand the comments of "I will literally not spend a single minute configuring my editor". I guess it's the systems developer in me that can't fathom someone that wants to use a tool to make a living without understanding it fully and being able to tweak it to their exact liking over the course of their entire career.
I personally consider my investment into Vim one of the best I ever made. If dumb college me can do it in a few weekends, you can do it. I recently setup Emacs and got it to the same level as my Vim usage in about two days of tinkering just for fun. Then again, I suppose some people are just here for the money and want to clock in and clock out as fast as possible. I really wish I could share with you the joy of tinkering, learning, and growing your knowledge about how these wonderful machines work.
Edit: Also to note - vscode supports editing files anywhere over ssh as well, so there isn't a huge advantage to neovim there.
I don't want to use my valuable time learning how to get vim working in some super-optimal way that's hypothetically going to improve my productivity by 1%. JetBrains consistently works well enough for me that I'm not going to bother switching. 90% of my life is spent thinking about how to solve the problem so the editor is not the main constraint.
Bonus: my window manager has similar keybindings these days
As you said, by the end of the workday I was very comfortable with basic vim use.
The basics are very simple. You just get used to formulate a (weird) sentence of what you want to do in your head, abbreviate it and then learn (or configure) the buttons.
Filter bubbles, dude. ;)
Everything is just a just for me ^^
I'm a committed (neo)vim user, but I readily admit I only got over the hump because I thought it was cool and hardcore and typing is easy for me. There's no question it's been worth it for me, and I would argue it's probably worth it for most people and better for the software ecosystem as a whole (GUI tools don't compose), but still I think trying to say one's better than the other is too narrow a view.
Is it enough to know how to enter insert mode, make an edit, then save and quit? That's easy enough to learn in a weekend.
Or is it learn how to edit efficiently using the various vim commands? That will indeed take much longer than a weekend.
(Even getting it configured just the way you want to will probably take more than a weekend...)
That's Notepad level usage, you don't gain anything from it.
* I mostly write Kotlin/Java for backend, desktop and Android projects. JB has that covered: Gradle integration, refactoring, navigation, dependency updates, documentation viewer, visual git log/diff/merge/rebase/blame, visual Android layout editor, visual JavaFX/Swing layout editors, run configurations, step through debugger that shows current variable state on top of my source code, all the android resource/variant stuff, test runners, trigger tests from source code, tool windows for docker (compose) or other services and probably much more.
* I do C/C++ development on some projects in Clion which has most of the stuff from above but :s/Gradle/CMake/g.
* Aside from the above I also use my IntelliJ Ultimate for Python, Ruby, Golang, Rust, Markdown, Mermaid graphs, Kubernetes yamls and Terraform hcl files, Lua and probably some more. All with the excellent IdeaVIM plugin so I have my modal editing and ex commands.
I gladly pay $600/year for all this. If I have to spend one day (likely more) on configuring vim/nvim to even do a subset of what I mentioned, then JB is cheaper.
So, that is why I switched from years of Vim use (and a couple years of Emacs before that) to JB and I haven't looked back. I don't see why I should artificially limit myself to vim/terminal only when JB+IdeaVIM gets me the best of both combined.
Different workflows.
If a terminal-based workflow is not your thing it's a tougher sell.
In the same time period, I've watched plenty of my cohort jump between IDEs and "modern" editors as they come and go (jetbrains, visual studio, textmate, sublime text, vscode, the various storm ides, etc etc). They all have to put time and effort into getting comfortable and proficient in each of these environments. That time adds up to be more than my initial vim investment.
Now I'm one of those folks that likes to master my tools and craft my own tools as well, so I've continued to invest time in my vim mastery. The same argument applies here too: that time is cumulatively increasing my skill at the tool rather than getting to the same point with various tools (cf the old interviewing dilemma: does this person have 5 years of experience or 1 year of experience 5 times). It means that some years I don't spend any time thinking about my vim setup, and other years I'll throw a few hours at it - importantly, this happens when I want not when the tool decides to release a new version that breaks things, not when theres suddenly a new great thing I have to use to keep up.
In summary - from a time/effort efficiency point of view for the course of a career: vim wins because the tool was there when I started, and its still here long after the "better" alternatives have come and gone (or faded into obscurity).
A tool that can last a lifetime and be used for any programming language at that.
It's just a trade-off between optimizing for the short-term or the long-term.
I just don't see it? I spent a good 6 months only using vim to see if I could get it to stick. Then I took a year break. After the break I forgot nearly every shortcut I was using minus a select few. I never got to the point of even matching my efficiency in other editors, let alone surpassing them.
6 months alone is already more than what I would consider worth in regards to time spent learning a tool for the little gain I see it bringing over just using intuitive, albeit less efficient, alternatives.
Also, although historically that hasn't really been part of the Vim ethos (compared to Emacs at least), you're expected to mold your editor over time to suit your needs exactly.
I do think 6 months should be enough to see some benefit in your workflow (like ci" to delete everything between "" and go into insert mode or Ctrl-O to go back to the last place you jumped from).
But I guess it depends on how you practiced, and if you look at those 6 months I'm sure you'll see that the time spent on actually learning Vim (struggling to learn these efficient editing patterns) was much less than you'd think.
With a tool like Vim I don't think it's enough to just use it, but we need to put conscious effort into it to learn it properly.
So it's just a claim.
Every time i do pair programming, i always get the "wow how did you do that?!?" response. It's just SO much ahead of an IDE in so many ways. Modal editing (imho) is far superior to "just insert mode" style of text editing.
With neovim (and vim + coc before that) i get 95% of what an IDE could give me, and the last 5% (like some obscure refactoring stuff) is something is would probably never use.
TLDR. I think learning vim is like learning SQL. It's a cross language tool, that will massively benefit your entire career.
I say this as someone who uses both the editors I mention depending on context.
Most people just don't think it's worth it, when the existing tools are Good Enough for them.
But once you pass the initial obstacle, vim/emacs/derivatives are really nice to use, and there are plugins for literally anything out there.
Still, the fact is that you have to know what to install. It's not like the NeoVim manpage mentions any LSP clients. So it requires a lot of tinkering, reading and participating in the community to figure out how to do stuff. That's exactly opposite of 0-configuring.
If NeoVim could bundle an LSP client with it, and have a config key to enable it, that'd be dope.
https://paste.sr.ht/~mjlbach/1a1df5cd61627e87ea4c4355a0473bf...
After all that, yea I'm more productive but I think the large barrier of entry to CLI editors is what keeps people using IDEs and their Electron cousins.
Are people seriously training their muscle memory to the default vim keybinding that is so cryptic I don't know what to say.
Since the early days of learning vim, I've changed the "go to end of line" bound as "-" which is next to "0" for "go to start of line" which is way more logically placed than some "^" that even needs shift pressed.
If anyone thinks "because default works on any machine", you need to think how you're wasting your brain cycle on unnecessary complexity for no reason.
Nobody does that on purpose. It's just a side-effect of learning Vim.
I've just never gotten around to learning vim in a more advanced way than edit, replace, copy paste, skip to line and search.
Any good suggestions on where to start? I looked at Spacevim but that seems to just throw everything at you.
IMO that approach makes the most sense too.
To get the muscle memory, try blocking the arrow keys in your config or even hiding the cursor (I'm serious, I once had this unintentionally and realized that because I was so used to Vim movements I didn't even need to see the cursor in normal mode).
The vim way is: stay in normal mode, learn to move efficiently with searching, jump to char, forward/backward words etc.
Don't use a prepackaged config. Refrain from plugins until you know for sure what you want.
It’s a pretty gentle introduction to vanilla vim over 4 weeks. After that point I’d recommend using nvim and all the plugins you want to make life easier, but learning The Vim Way is very powerful
Meanwhile my Vim go brrrrrr :D
Seriously, there's a huge benefit to not constantly switching and learning new environments (admittedly since Neovim / switching to Lua for scripting Vim there's been a lot new but all things the community wanted)
While vscode's ssh option is cool, it still requires that you have it installed on your local machine and while the web based version doesn't have that issue, it's missing other features (like ssh).
So for me the biggest motivator for switching to nvim has been the ability to connect to my machine and work on code from any device (ie even android) anywhere, only needing access to a terminal, and if I need to work on someone else's machine, having my environment there is as simple as cloning a git repo with my .vimrc
> it is intensely gratifying to build and improve the world around you.
For many of us, we expect we will be spending a significant chunk of our lives in the text editor.
Picking a dumb, inert, fixed, limited text editor is an apalling choice to some, versus picking something that has rich means of working the system (text objects, spellcrafting on the fly!!!) and infinite possibility (that flexible configuring, leader keys of possibilities). Picking a starting point where more is possible, where building & growing our world can be done- it's a path of lifelong struggle, but immense lifelong gratification, one where we will see our world florusihing and ourselves growing within in.
I personally resist a lot of the configuring & addition of plugins, am only an ok advanced vim user. But Im pretty ok at writing macros when i have a shitty chore, i make use of registers to handle reusable text- I appreciate having something much closer to a programming language than a input box at my back, and i keep slowly improving.
Vscode or Jetbrains or any other integrated software is from the ground built up to have its tools work together 100% of the time. I like vim fine if I edit something without any plugins needed but otherwise I'll stick with an IDE. And if I want vim controls I'll just turn them on the IDE because conceptually for me it makes more sense to port keyboard controls to an IDE than to port the entire IDE to a terminal
Practical example, look at the instructions to set up an ide-like ocaml environment with neovim[1]. It requires basically to install half a dozen tools by hand and to fix the linter config before you've even started. In VsCode it's literally one click.
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.
That's a bit of an overstatement, because I really do love vim/nvim and nvim integration isn't that good, but the fact is that adding a feature in nvim still means researching and configuring it where in something like VSCode you open a new filetype, it asks "do you want support for this file", click yes and you're ready to go. I can spend a few days trying to get vim to work in the way I want it for a specific filetype/framework, or I can get 90% of what I want from VSCode in 30 seconds and still have vim navigation and command support.
After about a week of using vim it clicked and I knew I couldn't go back to Sublime Text.
As for VS Code, I do everything I can to keep Microsoft products out of my life.
Statements like this are common, but they confuse two usages: (a) learning vi/vim well enough in order to use it in any unix environment vs. (b) using vim with a complete plugin/config suite as a primary development IDE replacement tool.
The former is IMHO an essential unix skill, but it's incredibly inefficient to try to use core out-of-the-box zero-plugin vim as a primary development tool. But once you start configuring an efficient dev environment, the GUI editors start to really outshine vim, and they still provide core vim functionality via plugins if you want it.
What I really meant to convey is that I dipped my toes in just enough to get familiar, and that was enough for me to get fully hooked on vim. I've spent lots of time trying to make Jetbrains/IdeaVim and VSCode/vim-plugin work for how I write code. Significantly more than I want to admit publicly...but I come back to the boring old terminal every time.
I am not trying to convince any person on this planet that they should use vim. In fact, when other developers at work ask me if they should try I say "No" 100% of the time. But Jetbrains/VSCode are a firm step down for my workflow.
My issue with Vim is remote servers and containers never have my (awesome) config.
It still pays off to know some basic Vim keybinds. You can often use them in other applications and every once in a while some machine only has vi. That said I grew up with DOS, do ctrl keybinds feel natural to me. Its just nigh annoying switching from macOS to Linux given the position of ctrl/fn/alt/super are different.
Sure, VSCode is a power hog and it's slow, but I make pretty good money so the cost of a more powerful development machine is trivial compared to the opportunity cost of doing all that research. Some years I really enjoy learning all about new ways to configure vim/nvim, but I recognize that it's really not an efficient use of my time, it's just been something I do more for fun.
For me a snappy editor experience, and vim in general, is about comfort, not optimizing for some theoretical top editing speed. I don't think I'd be a drastically worse programmer if I were forced to use windows notepad to edit code, I would just be more uncomfortable all the time.
My .vimrc clocks in just below a humble 500 lines. VSCode gets me more with practically zero configuration out of the box; a few clicks to install relevant language extensions and that's it. It's more stable and more performant on large files (e.g. 2+kLOC Python modules). RemoteSSH and RemoteWSL plugins are 100% pure gold.
I made your same argument for years to a buddy of mine that always used WebStorm (I'm a Python dev and he kept pushing me to try PyCharm). A coworker pushed me to try PyCharm since we're on Windows and I haven't really looked back. I even bought CLion.
If you can point me to an easy debugger to set up in neovim I'd probably be right back, but I can't. Couldn't figure out how to set up vimspector. And in PyCharm, at this point, I find it has better tooling than coc (I haven't wanted to spend the time setting up LSP/treesitter).
Furthermore, doing development in wsl isn't that great in my opinion and native windows neovim isn't either, even when using Windows Terminal. Its slow when handling a massive repository. FZF with ripgrep still works massively faster than telescope for my main work repository. I mostly dip into wsl when I want to do complex grep/sed/find operations and to make edits to my hledger timeclock sheet.
But one thing I've found to be a killer app for Pycharm Pro: vim keybindings in jupyter notebooks. Works way better than the plugins for Jupyter Lab.
IdeaVim is sometimes kind of disappointing, I wish JetBrains would just add a neovim plugin (I want to use vim sandwich instead of vim surround but alas). Still, it's good enough.
If you prefer Vimspector:
Thank you David, they're a fantastic overview of these plugins!
I work on kernels and various pieces of the boot process, so my needs when it comes to debugging aren't a typical case.
All those features you've listed aren't anywhere on the homepage, how does one even do that? I'm interested in learning more, but to think one can do this in a weekend just isn't true.
While I'm sure I could figure out all these kinks, its just software, it's the time sink that makes me pause. I don't see the value here, but I also don't know what all it can do compared to my current workflow with VSCode.
Fonts are better, colors are better, it is faster, less latency, running a terminal inside your editor works better, pop-ups and overlays work better/are more flexible/easier to read, mouse interactions work better, resizing works better, it is easier to run multiple windows, it is easy to run multiple different fonts with different font sizes, etc etc.
I also don't have to figure out solutions to conflicts between the keyboard shortcuts between the shell, the terminal, the terminal multiplexer (screen/tmux/tabbed terminal emulator), and the editor.
> I can use my editor over ssh and edit anywhere
I can just have my editor use ssh to edit files anywhere. Remote editing is a thing.
Anyways for proper system hygiene you shouldn't be shelling into anything except to troubleshoot problems or for checking things you don't have monitors in place for. This is why we have things like ansible or puppet.
In fact the whole insisting on having an editor in a terminal emulator thing is probably holding Nvim back as a whole. Which is why you don't see the obvious benefits.
Since the community wants to use terminal emulators so heavily then all the add-ons and features of the editor must support the lowest common dominator between desktop apps and terminal emulator, which is almost always going to be the terminal emulator.
Just remember that you are not avoiding a GUI by using a terminal emulator. It's still a GUI. Just a GUI designed for running command line applications in a Unix-style shell. And Neovim really isn't even a command line application.
It's really not difficult at all. I and others have probably a million things we would like to tinker with (yes, including tweaking a text editor), but we all have a limited time so we end up with priorities. It just happen that I didn't make a priority to tweak vim/neovim because I'm happy with my current code editing setup. For other kinds of software, I may not be happy at all, to the point of writing my own.
See: different people, different expectations. Your choice being right for you doesn't mean it's the right choice for everyone. Tolerance 101.
I can use VS Code in the browser: https://github.com/coder/code-server
> it starts up instantly,
I launch my editor once a day. Why do you need to keep killing and starting your editor?
> and it's completely free and open source,
OK, so is VS Code, or at least the OSS version, which has all the key features anyway.
> not driven by a corporation,
So this is your philosophy.
> and there's decades of documentation on how to use it.
Most of it out of date, probably.
> I guess it's the systems developer in me
Guess what? I'm a systems developer too! I also work on the kernel! But I use VS Code.
> that can't fathom someone that wants to use a tool to make a living without understanding it fully and being able to tweak it to their exact liking over the course of their entire career
VS Code is open source, so there's nothing stopping me from diving in if I want to. And it's also highly extensible.
Now that I've answered all the supposed benefits you list about (neo)vim, I have one question:
Can (neo)vim show text in two different font sizes? Or fonts? Like, what if I want my documentation popups to show up in a sans-serif font? No, don't tell me I have to open up the documentation in a browser or whatever. I want it in the popup.
If I just need to edit a file, or view it, I'll often use vim. If I need to sit down and actually code? Intellij every time.
If vi had never existed, and you introduced it today, people would think it was some sort of april fools joke of an editor. It is the least intuitive and user friendly piece of software I've ever used. The only reason I continue to do so is because I've learned it's quirks and it's stockholm syndrome now.
Suppose you're using VSCode/Jetbrains with proper keyboard shortcuts (stuff like expanding selection, search/highlight all matches, ...) - basically never using the mouse. Is navigating / editing with NeoVim really that much faster?
Let me know how to highlight SQL in strings and make tables linked to remote database over SSH and autocomplete table names and column names as I type. And make sure that its grammar is checked against specific RDBMS's available syntax.
And I also want code formatting that's not entirely opinionated, so I can decide what gets wrapped and what gets indented and let it format an entire folder with a shortcut.
And if I'm setting the project to use PHP 8.0, make sure to highlight features I've mistakingly used from 8.1, so that I don't get runtime errors.
And if I'm editing files over SSH, make sure that if the remote file is changed, it warns me before I upload a local version, so I don't accidentally overwrite any remote changes and give me the option to merge.
And for sake of being right, in PHP if I have a function paremeter set as a string, highlight "is_string" check on the parameter as redundant, so my code doesn't look dumb.
I probably have others and even more that I'm not even aware of from its feature lists that can be useful over what vim/nvim can offer after taking some months configuring it to my liking.
I suppose you're comfortable missing out on those?
vim to me is a server config editor.
There are a lot of examples for Vim but found very few up to date for nvim.
It comes with LSP and treesitter configured out of the box.
Neovim on the other hand is heavily customizable, but you also have to do this for awesome functionality
Configuring Neovim from scratch is part of the fun of learning your editor and isn't that much work.
Defaults matter
The potential DSP integration is nice too. And to top it all off, it's made in a language i enjoy and within the first 24h of using it i had a PR made for a small feature i wanted. Being able to contribute in a language i enjoy was nice.
I wish helix had a mode where its keybindings become the same as that of neovim for easier transition. After years of using (neo)vim, it's almost impossible for me to switch to a different set of modal keybindings. I always ended up pressing x to delete characters in helix which, in turn, ended up selecting the entire line.
:term
One thing i do use it for: In neovim there's options to open the terminal as a sort of overlay on top of the existing splits, they call it floating term. Its really nice for opening tools ( e.g. lazygit or a test runner) because find it a bit less disruptive than having to bounce in and out of the editor by other means.
Because running tests doesn't necessarily play nice with quickfix?
I do set the make program to build and get errors via the quickfix when there isn't a good lsp server for the language. When there is an lsp server for the language, why bother with a special make command? - the same info is just populated inline for you.
I tend to use quickfix lists because I can edit/filter/persist them; so for example I'll have some tests/warnings but won't care about them for the moment but then rerun the command and get the diff and navigate to that.
It's fairly complicated to script the same using the LSP api.
I don't remember if it's enabled by default, but I have this in my ~/.tmuxrc (where pbcopy is the excellent https://github.com/skaji/remote-pbcopy-iterm2/blob/master/pb...)
# Enable vi mode
setw -g mode-keys vi
# Copy to host
bind-key -T copy-mode-vi v send-keys -X begin-selection
bind-key -T copy-mode-vi y send-keys -X copy-pipe "pbcopy"
unbind -T copy-mode-vi Enter
bind-key -T copy-mode-vi Enter send-keys -X copy-pipe "pbcopy"
I remember vanilla vim doing some weird stuff, like leaving the buffer open even though I've exited the shell, requiring me to close it manually. I don't know if it's been fixed since.
`:term ++close <cmd>`
- I have a theory that using `coc.nvim` is still the superior solution even compared to a native LSP. Why? Cause we can siphon from the huge man-hours of development and polish that M$ has put on VSCode. Every time they tweak VSCode, we at downstream, enjoy the benefits. Am I wrong in my assessment?
- Vim's regexp-based syntax highlighting is annoying. So I think nvim+tree-sitter is the better solution on this front
COC is way easier to set up and the default config is fine.
CMP is lighter and more configurable, and it works really nicely with luasnip (my snippet engine of choice).
Under the hood they both use the same LSPs, but COC pulls them down and sets them up for you.
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.
You have to assemble more plugins to recreate the functionality coc provides as a whole and the documentation on the config process is sparse (as of my last attempt to use it). I’m also probably a weird edge case in that my primary use case is writing Powershell. Coc just works and getting native LSP configured and working requires more time than I’ve been willing to give it.
Both coc.nvim and the built in LSP implementation use basically the same Language Servers, so whatever updates happen to the server will benefit either approach.
However, coc.nvim DOES have a large community that has built a neatly packaged LSP client framework (and many other tie-ins like completion, snippets, formatting, and things like auto-pairs) that is a much more cohesive experience. The built in LSP is best at providing a solid baseline client for those language servers if you really want to tweak everything to exactly how you want it.
If you like that approach where you don't want to configure everything yourself, coc.nvim is probably the "superior" approach for you.
If you have ever said the word "bloat" unironically on your computer with 64G of RAM, built in might be for you.
I really just want one config that works on:
* Yes, my Ryzen 5 with 32G of RAM
* My Pinebook Pro with 4G of RAM (and like 3.7G accessible) (and limited storage as well)
* My jump host / gateway VM with 512MB of RAM (and even more limited storage than the PBP)
So pulling down and running node.js to use coc.nvim has never been something I was interested in. Before nvim-lspconfig I used LanguageClient-neovim (a Rust client).
This. Learned it the hard way. For many moons, I tried integrating YouCompleteMe and the like. Then one day, I just gave up and switched to `coc.nvim`
https://github.com/python-lsp/python-lsp-server
Rust analyzer is written in Rust, gopls in Go, clangd in C++, R language server in R, Jsonnet language server in Go, sqls in Go.
This is usually where I check out when I get the urge to redo my vim setup. The fact that completion, auto pairs, snippets, and something like endwise are all at odds with each other isn't something I want to deal with.
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)
I found that the native LSP's community to be too quickly changing. Plugins that were necessary earlier weren't, while new necessary plugins came into play. But, coc.nvim was steady chugging along and my old settings file worked out of the box.
I'm also not a huge fan of just the sheer amount of plugins that use the LSP. It seems like every plugin has go-to functionality.
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).
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.
Or if you prefer living in the terminal, curl https://nvim.sh
You only have to install it once, and update things like update-alterrnatives or play with $PATH.
https://github.com/neovim/neovim/archive/refs/tags/v0.7.0.ta...
and untar into a local ~<user>/usr/local directory that I maintain myself.
Compiling is neovim at work is a hassle, since its dependencies are from sites which are behind a firewall. So I decided to use locally built dependencies. The most painful part was getting the 3 luarocks 5.1 (which is not the latest) packages to compile locally and work with neovim.
https://stackoverflow.com/questions/38387964/is-it-possible-...
Example 1:
nvim .
let g:netrw_preview=1
let g:netrw_banner=0
let g:netrw_browse_split=4
let g:netrw_liststyle= 3
let g:netrw_altv=1
let g:netrw_winsize=8
Example 2:
set number
Example 3:
set mouse
After setting up my .vimrc file with sane defaults and a bit of an attempt to use the editor in earnest, my conclusion is that Vim/Neovim is just a bad editor.
I want more from my editors.
Here's a .vimrc file that attempts to make Vim and compatible editors more like Visual Studio Code, Atom, and Sublime Text:
https://github.com/andrewmcwatters/dotfiles/blob/main/.vimrc
And it's still bad.
I agree that certain settings shipped with neovim could be expanded. There should really be a process to elect plugins and settings that are generally accepted as "good" for neovim.
Plugins like Gruvbox, vim-surround, coc.nvim, vim-plug, nerdtree etc. have been continuously maintained for years, why not make it easy for new users to install and use them without having to go on the path of wonder?
If I have to remember "ok line 7000 is where the weird permission business logic starts" that's a failure to comment and make clear how the code is structured.
If tooling is telling me there's a problem on a specific line then I should have a code action or command to take me directly to that line, I shouldn't have to juggle navigation manually.
The intention is for it to serve as the core technology for any number of vi-like text editing setups. It's not batteries-included, but there are batteries everywhere if you look.
Mouse is off by default. Again, why? I get that it's a terminal editor, but if the technology is there to allow me to select text with my mouse, why do we need act like luddites?
After setting up my .vimrc file with sane defaults and a bit of an attempt to use the editor in earnest, my conclusion is that Vim/Neovim is just a bad editor.
> MessagePack structured communication enables extensions in any language
Is anyone writing extensions in other languages? Does it work well?
Neovim is literally a vim fork, with .lua supported everywhere .vim is used and many other additions/changes/removals.
It's not 'vi with lua support' it's a totally different core paradigm like the difference between vscode and vim.
Someone recently wrote a whole screed about this and itemized a bunch of points about why exactly it's backwards to integrate a terminal vs working within any terminal, baking in more limited answers for things that are already answered more flexibly by plugins and external processes, etc. They got a little bit screedy and there were a few nits to pick, but the basic points were all both true anc valid.
It was posted to HN within the last couple days but I can't find it now. If I find it I'll add the link here.
All of which is not to say that neovim is necessarily a bad thing, it's just that it's not a newer or better vim, and the starting point being a fork of vim doesn't mean a thing.
The first Tesla was a fork of a Lotus.
Both Tesla and Lotus are fine cars, but a Tesla is not a newer better Lotus.
If you like the design goals of Lotus, then a Tesla is utter garbage.
And the inverse is exactly the same true. If you like the design goals of a Tesla then a Lotus is utter garbage.
If I were either Lotus or a Lotus user, and even if cars were open source projects without legally enforcable trademarks on their names, I would be highly highly annoyed when someone comes along and takes the current Lotus and replaces the engine and transmission with electric motors and a PC, and slaps a huge ipad on the dash, and then names it "NeoLotus", and then continues to call it NeoLotus even after the original Lotus base isn't even in there any more and it's a totally different thing with a totally different set of priorities, goals, philosophies, and audience.