Three months after switching from Vim to Neovim. The core promise of enhanced plugin compatibility and LSP integration is real, but the migration path is littered with subtle, time-consuming incompatibilities. My primary motivation was a more stable language server experience for Python and Terraform work, which has largely been achieved. The cost was a non-trivial amount of weekend hours untangling plugin interactions.
The main compatibility issues fell into two categories:
* **Plugin Bloat & Startup Time:** Several popular Vim plugins have Neovim-specific forks or Lua alternatives. Blindly porting my `.vimrc` led to redundant functionality and a 120ms startup time. The solution was aggressive pruning and migration to Lua-based plugins. For example:
* Replaced `vim-polyglot` with tree-sitter and targeted syntax plugins.
* Switched from `fzf.vim` to `telescope.nvim`.
* This cut startup to ~40ms.
* **LSP and Autocomplete Conflicts:** Running `coc.nvim` alongside `nvim-cmp` with an LSP source is a recipe for duplicate completions and erratic behavior. I had to fully commit to the native Neovim LSP client (`nvim-lspconfig`) and `nvim-cmp`. The configuration is more explicit, which is a net positive. Here's the core setup for Python:
```lua
local lspconfig = require('lspconfig')
lspconfig.pyright.setup({
settings = {
pyright = { autoImportCompletion = true },
python = {
analysis = {
typeCheckingMode = "off",
useLibraryCodeForTypes = true
}
}
}
})
```
**Current pain point:** File tree plugins. `NERDTree`, while reliable in Vim, feels sluggish and can interfere with buffer focus in Neovim. I'm evaluating `nvim-tree.lua`, but its default keybindings are a mess. The search for a performant, unobtrusive file explorer continues.
If you're considering the same migration, my blunt advice: don't do a direct port. Treat it as a rebuild. Audit every single plugin for a native Lua/Neovim alternative, and start your LSP setup from scratch using `nvim-lspconfig`. The performance and reliability gains are worth the initial frustration, but go in with your eyes open.
- cr
Your fancy demo doesn't scale.
I'm a devops engineer at a mid-size SaaS shop (around 200 engineers, heavy Python / Terraform / Kubernetes stack). I've been running Neovim as my daily driver for about a year, and my team's entire infra config lives in a monorepo we edit in Neovim with native LSP. I also maintain a few internal Neovim plugins for our API integration tooling. Your 3-month report mirrors my experience, but I want to add a few concrete load-bearing details that might save you another weekend of hair-pulling.
**Core comparison of migration pain points (Vim plugins vs Neovim-native alternatives):**
- **Startup time vs plugin isolation:** You dropped from 120ms to 40ms by swapping vim-polyglot and fzf.vim. That's good, but I'd bet you're still loading a few legacy Vim plugins that block the event loop. In my env, going fully Lua-based (telescope, nvim-treesitter, lualine, nvim-cmp) got me to 22ms on a cold start. The hidden cost is that `vim-polyglot` actually does a lot of syntax highlighting for obscure languages that tree-sitter parsers don't cover yet (e.g., HCL's older version). I had to keep a tiny Vimscript snippet for that; it added 3ms but saved me from broken highlighting in Terraform 0.11 files.
- **LSP concurrency and autocomplete resource usage:** You mentioned running coc.nvim alongside nvim-cmp. I made that mistake for two weeks. The real issue isn't just duplicates - it's memory and CPU. coc.nvim spawns a Node.js process per file type, and nvim-cmp + nvim-lspconfig spawns a separate LSP client per language server. On a project with 30+ open files, I saw 1.2GB RSS from Neovim alone. Switching fully to nvim-lspconfig + nvim-cmp with `lazy.nvim` for lazy-loading dropped that to 400MB. The config gotcha: you have to explicitly disable the built-in `vim.diagnostic` display if you use `nvim-lspconfig`'s native diagnostics, otherwise you get double underlines. The fix is a single line:
```
vim.diagnostic.config({ virtual_text = false, signs = true, underline = false })
```
Then let `nvim-cmp` handle the popup. That alone fixed erratic behavior for me.
- **Plugin ecosystem maturity for CI/CD and non-interactive use:** This is where Vim still wins if you run batch commands in CI. Neovim's headless mode (`nvim --headless`) is great for linting and formatting, but some plugins like telescope are inherently interactive. I had to replace `telescope` with `fzf.vim` for scripted fuzzy finding in CI pipelines because telescope's `require('telescope.builtin').find_files()` doesn't work cleanly without a TTY. The workaround is to use `vim.fn.system('fzf')` from Lua, but that's another 10 lines of glue. If you ever need to run Neovim in a Docker container with no terminal, test your Lua plugin calls early.
- **Tree-sitter performance on large files:** Tree-sitter is faster than regex-based syntax, but the parsers are memory-heavy. I work with a 12,000-line Terraform plan file sometimes. vim-polyglot (regex) would highlight it in about 200ms. Tree-sitter with the HCL parser takes 400ms and uses 80MB more RAM. The trade-off is accuracy - tree-sitter catches nested blocks correctly. But if you're editing a huge file, consider disabling tree-sitter for that buffer or toggling to pure regex. I have a mapping:
```
vim.api.nvim_create_autocmd('BufReadPre', { pattern = '*.tf', callback = function()
if vim.fn.getfsize(vim.fn.expand('%')) > 1024 * 500 then
vim.bo.syntax = 'on'
require('nvim-treesitter').disable('hcl')
end
end })
```
That saved me from 1.5s opening delays on warehouse configs.
- **Configuration migration effort and Lua learning curve:** Porting a 200-line `.vimrc` to `init.lua` took me about 3 hours, but the real time sink was debugging implicit state. Vim plugins often assume `g:` variables are global; Lua plugins expect `require` and lexical scoping. I had to rewrite a custom snippet plugin because it relied on `g:loaded_*` guards. The total migration cost for my setup was about 12 hours over two weekends, including testing all plugins in a headless CI env. If you have more than 40 plugins, budget 15-20 hours.
**My pick:** Stick with Neovim for any workflow where LSP and tree-sitter give you a clear accuracy advantage - Python, TypeScript, Go, Terraform, Lua. The startup time win and native LSP integration are worth it. But if you do heavy batch processing (CI linting, headless refactoring) or work with files > 5000 lines regularly, keep a Vim fallback or a minimal `--clean` Neovim config. Two things that would help us give you a cleaner recommendation: what's your primary file type breakdown (e.g., 70% Python, 20% Terraform, 10% YAML) and do you run Neovim inside tmux / SSH sessions or mostly locally?
connected