Neovim 0.12.0

Original Article ↗ Hacker News Discussion ↗

Versioning, Roadmap, and vi Compatibility

  • Some wonder why Neovim is still <1.0; others point to an explicit roadmap where 1.0 mainly depends on stabilizing the RPC API and Lua stdlib.
  • Strict vi compatibility is explicitly a non-goal. The changed :! behavior (non-interactive, piped output) frustrates users who prefer classic Vim/vi semantics; workarounds exist but no core reversal is expected.

Built-in Plugin Manager vs lazy.nvim

  • 0.12 adds vim.pack, a minimal built-in plugin manager.
  • Supporters like that it’s simple (vim.pack.add({url})) and part of core; critics say replicating lazy.nvim-style features (lazy loading, dependencies, rich specs) quickly becomes verbose.
  • Some argue lazy-loading should be driven by plugins and Neovim hooks, not the manager; others are happy to keep lazy.nvim because it’s more featureful today.

LSP, Treesitter, and Upgrade Pain

  • The new native LSP configuration (vim.lsp.config / vim.lsp.enable) deprecates nvim-lspconfig patterns; docs and guides exist but users with complex setups report multi-afternoon migrations.
  • Mason is now “just” a tool installer; some drop it and manage servers via OS tools.
  • 0.12 changes to nvim-treesitter and incremental selection require config updates; there’s a new built-in AST-based selection (v_in).

Vim vs Neovim vs Other Editors

  • Some Vim users feel FOMO from VS Code but are told:
    • VS Code (and Cursor, Zed, Helix) has strong multi-cursor, AI, and IDE UX.
    • Neovim leads on LSP/treesitter integration and Lua-based extensibility.
  • Several note most new ecosystem development targets Neovim; others prefer classic Vim for perceived stability.

AI/LLM and Claude Workflows

  • Many use Claude/other LLMs alongside Neovim in terminal splits, tmux panes, or via plugins (e.g., for inline edits, docstrings, agents).
  • Some report entire coding/debugging workflows driven by AI, with Neovim as a lightweight front-end; others prefer minimal “ghost text” assistance or keep AI-heavy flows in editors like Cursor.

Multi-Cursor and Editing Philosophy

  • Upcoming multi-cursor support (0.13) generates debate:
    • Fans cite fast ad-hoc refactors and visual WYSIWYG edits, inspired by Sublime/VS Code/Helix/Kakoune.
    • Skeptics argue macros, visual block mode, and regex substitutions already cover most use cases and better match Vim’s modal model; many see multi-cursor as complementary rather than a replacement.

Build System, Stability, and “Batteries Included”

  • Switching to the Zig build system is seen by some as a path toward incrementally rewriting C code in Zig; others say it’s mainly a nicer C build tool than CMake.
  • Opinions diverge on Neovim’s stability: some call it remarkably solid even on main, others point to breaking LSP APIs and keybinding changes.
  • There’s ongoing tension between:
    • A desire for more features in core (LSP-like, picker, DAP, plugin-manager) to reduce plugin bloat and supply-chain risk.
    • A preference for a lean core where most experimentation and complexity live in plugins.

Workflows, Performance, and Learning

  • Many describe a terminal-first workflow: Neovim + tmux/zellij + LSP + low memory usage, often replacing heavy IDEs and easing remote/SSH work.
  • Others miss richer GUI/desktop integration or don’t want “configuring an editor” as a hobby, preferring Helix or VS Code.
  • Several recommend curated Neovim distros (LazyVim, AstroNvim) or learning resources/games to move from basic Vim motions to “power user” levels.