[HN Gopher] Neovim 0.12.0
___________________________________________________________________
Neovim 0.12.0
Author : pawelgrzybek
Score : 251 points
Date : 2026-03-29 17:39 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| benrutter wrote:
| Always interesting when a project stays 0 ver for so long- anyone
| close to the project know what would be considered significant
| enough for a "v1" release?
| nicebill8 wrote:
| Possibly never: https://0ver.org/
| suby wrote:
| There is a roadmap and github issue tracking what is needed for
| 1.0.
|
| https://github.com/neovim/neovim/issues/20451
|
| https://neovim.io/roadmap/
| kps wrote:
| Maybe when `:!` works the way vi does and POSIX says it must.
|
| Just kidding, that will never happen.
| markrian wrote:
| What are referring to, out of interest? Does this apply just
| to nvim, or vim as well?
| PhilipRoman wrote:
| In Vim, :! cleans up the tty context and hands it off to
| the child program, to do whatever it wants, you can open
| any TUI program and it will work as expected. In Neovim, :!
| just uses a plain pipe. Actually I believe GVim has the
| same problem. Since both Vim implementations now have a
| built in terminal handling stack anyway, I wonder if that
| could be used to unify the behavior.
| djb-at-durable wrote:
| Just nvim. Neovim runs :! commands non-interactively,
| capturing the output in a pipe. vim, on the other hand,
| suspends itself and runs the command in an external shell.
|
| This isn't a problem, really, for non interactive commands,
| but causes issues with interactive ones. I personally
| prefer vim's approach, though not enough to abandon neovim.
| flexagoon wrote:
| vi compatibility is explicitly a non-goal for neovim
|
| https://neovim.io/charter/
| saint_yossarian wrote:
| AFAIK it's mostly about stabilizing the RPC API and Lua stdlib:
|
| https://github.com/neovim/neovim/issues/20451
| mi_lk wrote:
| > - d21b8c949ad7 pack: add built-in plugin manager `vim.pack
|
| Can someone try to sell me this over lazy.nvim? I asked Claude to
| convert lazy config to pack and I was not happy with it because
| how verbose it turned out
| c-hendricks wrote:
| I'm assuming there will be something like lazy.nvim built on
| top of vim.pack. Some of the conventions might go away (ie
| constantly calling `.setup`).
| pawelgrzybek wrote:
| Have a look here. This is incredible guide to the `vim.pack`.
|
| https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....
| NegativeLatency wrote:
| It being built in sounds nice, although I have some lines in my
| config that automatically install lazy if it's missing.
| tekawade wrote:
| Tried to switch but found lazy.nvim better
| flexagoon wrote:
| > how verbose it turned out
|
| Verbose? The new plugin manager's interface is literature just
| vim.pack.add({url}), not sure what is verbose about that
| lawn wrote:
| If you want to replicate the lazy features then it will get
| verbose. Even using a dedicated plugin for lazy loading it's
| not as tight as lazy.nvim.
|
| You may argue that you don't need lazy loading, which is
| fine, but they're not 1-to-1 compatible.
| PhilipRoman wrote:
| I always thought Vim/Nvim already had a built-in package
| manager, git clone inside ~/.vim/pack/*/start, am I missing
| anything by not using a "real" package manager?
| Jare wrote:
| I imagine you are left with manual dependencies, manual
| updates, and possibly without lazy loading or portable
| configuration. That stuff is not strictly necessary and may
| be easy to roll your own if you're very into it, but it's
| comfortable to have a standard.
| leephillips wrote:
| Not really. That's what I do.
| alwillis wrote:
| > I always thought Vim/Nvim already had a built-in package
| manager
|
| They do; I used minpac [1] back in the day with Vim. And now
| Neovim has vim.pack.
|
| Every so often, a movement to create Vim and Neovim
| configurations with zero (or minimal) 3rd party plugins
| becomes popular. This means no lazyvim as the package
| manager.
|
| The lazyvim package manager has all the bells and whistles,
| especially lazy loading plugins, which reduces Neovim's
| startup time if you have dozens of plugins installed. My
| LazyVim [2] configuration has 35 plugins total but only 6
| load at startup; startup time: 76ms. Plugins you don't use
| often aren't loaded unless necessary.
|
| [1]: http://vimcasts.org/episodes/minpac/
|
| [2]: https://www.lazyvim.org
| c-hendricks wrote:
| I unintentionally ran the main branch when testing some changes
| and a lot of my config broke (mostly around LSPs, CodeCompanion
| was much slower streaming its responses) so might wait a bit
| before upgrading.
| vermilingua wrote:
| The lspconfig depreciation was a very painful upgrade for me
| too, as it seems to be very poorly documented; but ultimately
| it came down to moving all of the LSP server configuration to
| `vim.lsp.config` blocks, then calling `vim.lsp.enable` with all
| the servers I use.
|
| I'm still not clear on what Mason is doing in my config after
| the switch but oh well.
| justinmk wrote:
| It's documented here (with migration steps):
|
| https://github.com/neovim/nvim-lspconfig#important-%EF%B8%8F
|
| and in a pinned issue.
|
| and nvim-lspconfig :help has a migration guide:
|
| https://github.com/neovim/nvim-
| lspconfig/blob/16812abf0e8d81...
| stryan wrote:
| Mason installs LSP servers (and other tooling if desired). So
| if you're managing your LSP servers elsewhere (distro package
| manager, etc), it's probably not doing much.
|
| Mason was always just a package manager for LSP servers. It
| used to be you needed the nvim-lspconfig plugin to properly
| configure LSP servers to work with neovim; to help with that
| there was the mason-lspconfig plugin that basically mapped
| LSP servers (as installed by mason) to nvim-lspconfig LSP
| configurations to make it all Just Work.
|
| Now nvim-lspconfig and mason-lspconfig are no longer required
| thanks to the `vim.lsp.config`/`vim.lsp.enable` setup so you
| don't need them unless you want the little bit of automagic
| setup. Mason you can retain if you find it easier to install
| LSP servers through it, otherwise you can drop that too.
| Personally I manage my LSP tooling through distro/mise and
| replaced the lspconfig plugins with just a few autocommands
| and manually grabbing the config files from nvim-lspconfig
| git repo as needed.
| brcmthrowaway wrote:
| I'm using VIM - Vi IMproved 9.1. What am I missing?
|
| I'm kind of desperate to switch. Getting massive FOMO from
| colleagues using VS Code. But I really like using the keyboard to
| navigate. What should I do?
|
| Does NeoVim support Claude Code?
| wasabi991011 wrote:
| If it's just using the keyboard that's holding you back from
| VSCode, you'll be pleased to know it has plenty of its own
| shortcuts, as well as a "VIM navigation" mode you can turn on.
| brcmthrowaway wrote:
| What do you use?
| mathieudombrock wrote:
| Vim mode in vscode is not even close to emulating a real
| neovim setup.
| maleldil wrote:
| OP specifically mentioned "using keyboard to navigate". If
| that's all you need, then VSCodeVim can get you pretty far.
| lawn wrote:
| What are you getting FOMO over? Been using Neovim since it
| forked from Vim and I'm very happy with it.
|
| Lua has been a big boon to advanced configuration and the
| plugin ecosystem and Neovim supports everything I'd want and
| more. LSP and treesitter for instance are still better handled
| by Neovim.
|
| If you dislike Lua (I'm not a fan) I recommend Fennel, but
| either way it's much better than Vimscript.
|
| As for Claude there are at least two Neovim plugins for it. I
| use one of them and it works well but I can't remember which.
| normie3000 wrote:
| What's the FOMO caused by? Asking as a vim user starting to get
| FOMOOFOMO.
| pl-94 wrote:
| I motivated my Cursor-colleagues to switch to tmux+nvim -- they
| don't use it all the time, but they enjoy the vibe. Claude is
| running on some tmux pans. Much nicer than VSCode!
| johnsonjo wrote:
| I've been using VIM/NVIM on and off for a while and the one
| thing that made it stick for me over VSCode was LazyVim [1]. If
| you're missing out on something IDE like VSCode, but you love
| vim it's a great way to go (it can take some getting used to so
| hang in there). EDIT LazyVim is based off nvim by the way. If
| your more into videos to learn about something this is a good
| intro to it from Elijah Manor [2]. I have my dotfiles stored on
| github that I use on my different machines, and use gnu `stow`
| and `make` to build them and that gives me my specific lazyvim
| setup free and quickly after just downloading a few
| dependencies.
|
| [1]: https://www.lazyvim.org/ [2]: https://youtu.be/N93cTbtLCIM
| robrain wrote:
| To pile on to the LazyVim love, I recommend this site:
| https://lazyvim-ambitious-devs.phillips.codes/
|
| Course and book (free html, available pdf and dead tree).
| Covers everything I've needed concisely.
| NegativeLatency wrote:
| Used neovim and neovide for the last week (also had FOMO) and
| while they're good (no major gripes) I ended up going back to
| macvim.
|
| Are there specific features you're missing from vscode?
| tekawade wrote:
| You can use vim key binding in vs code.
| sequin wrote:
| Resist hypes and just use whatever you feel like. Torvalds uses
| a 40 year old EMACS implementation and that seems to be working
| for him.
| scuff3d wrote:
| Use the Neovim extension for VScode. It requires you to have
| Neovim installed, but it works way better then the Vim
| extension since it passes commands to neovim instead of using
| emulation.
| aldanor wrote:
| Most of the active development in the ecosystem is done for
| neovim these days. If you're using barebones vim then yea you
| probably won't see much difference, otherwise you have no
| choice
| lachlan_gray wrote:
| Ymmv, but I have been very happy using classic vim's "native
| claude support"
|
| :term claude
|
| It will also expand special characters so you can do something
| like
|
| :term claude "refactor %"
|
| And Claude starts work on your current file right away. Also
| your buffers will update with Claude's edits!
| shmerl wrote:
| I switched from vim to neovim at the time when the former
| didn't support true color themes and limited colors annoyed me.
| neovim offered true color support in the terminal so I switched
| and stayed with neovim since.
|
| One major difference is neovim allowing to use Lua for
| configuration and plugins. I find Lua to be neater than
| vimscript.
| kelnos wrote:
| > _Does NeoVim support Claude Code?_
|
| Why does it need to? Just open CC in another terminal window or
| tab. Or run it in a split inside vim, using `:term`.
| semiinfinitely wrote:
| why put a built-in plugin manager. and if so why make it pack not
| lazy
| TymekDev wrote:
| > The folke/lazy.nvim is the most used plugin manager at the
| time of this writing. And rightly so: it is very capable with
| lots of features. Ironically, this itself makes it not very
| suitable to be a part of Neovim as most of the features come
| with significant code and maintenance complexity. Plus the
| whole idea of treating lazy loading as the main goal of a
| plugin manager does not sit well with Neovim core team.
|
| https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....
| shmerl wrote:
| I'd stick to lazy.nvim for now. Lazy loading is really neat
| and lazy.nvim's ability to specify plugin dependencies isn't
| something vim.pack has either.
|
| I'd guess if you don't care about lazy loading and OK with
| just loading everything all the time - vim.pack is great to
| have as a built-in.
| helterskelter wrote:
| Up next for 0.13: multiple cursors! I have no idea what I'd do
| with this feature but it sounds intriguing.
|
| https://neovim.io/roadmap/
| steve_adams_86 wrote:
| I'm not sure how people typically use neovim, but in Zed I find
| multiple cursors (especially combined with multiple file
| buffers) extremely ergonomic for refactoring quickly and easily
| where tools like find and replace or simple renaming doesn't
| suffice. It lets you scan through and add cursors where you
| need them, then perform your edits across locations and even
| files all at once. It's so nice that it played a significant
| role in me keeping Zed early on despite it missing a lot of
| extensions I used in VS Code.
| gesis wrote:
| I am so used to sed-style, regex powered find/replace, that
| this use admittedly never occured to me. As a result, multi-
| cursor seemed mostly useless outside of pair programming that
| I never do.
|
| I will have to try it out once it lands in neovim just to see
| if I can wrap my muscle memory around it.
| runevault wrote:
| For me the nice thing about multiple cursors is when it
| would take more time to write the regex than it does to
| just throw down say 8 cursors and update the spots.
| skydhash wrote:
| There's an overlap between "Find and Replace" and Macros,
| but it's too small for multi cursors to be particularly
| useful for me. Especially with emacs where I can bring up
| all the lines in a separate buffer and edit them there
| (occur-mode) or do the same for a set of files (grep-mode
| and wgrep)
| wredcoll wrote:
| How do you place the cursors then?
| hiccuphippo wrote:
| In vim?
|
| Ctrl+v, 8, j, shift+i, add the text, Esc.
|
| Which works if you need to edit several aligned lines in
| a row. The one thing I'm missing is putting the cursors
| on the next found position of a search term which would
| make it much more useful.
| steve_adams_86 wrote:
| I've always told myself I should learn to do these
| sed/regex find and replace techniques, but my origins are
| not sophisticated and I use computers like that orangutan
| hammering nails in the video with David Attenborough
| https://youtu.be/IFACrIx5SZ0?si=NcWGBNq272KoYB2i&t=84
|
| It's entirely possible that you don't need multiple cursors
| bluecalm wrote:
| You have very convenient macros. If there is something you
| want to do in places you are going to mark first then you can
| just execute it right there instead. If it's just one edit
| you just do it right there without macro and use the dot to
| repeat it in more places.
|
| If those places can be created automatically then again it's
| just a macro you execute over many lines.
| thiht wrote:
| Not sure I under the Zed argument, VSCode has supported
| milti-cursors since the very beginning. It was made popular
| (not invented) by Sublime Text because it made it reaaaally
| easy (middle click+drag), so Atom and VSCode carried the
| feature.
| scuff3d wrote:
| It's funny because I miss this one all the time. I got use it
| in Sublime and VScode before making the jump to Neovim. I know
| you can get similar functionality from macros and what not, but
| it's just not the same.
| meekins wrote:
| Really excited about this! At least in Sublime Text I've found
| multiple cursors a really powerful tool for ad-hoc
| transformations on snippets of semi-structured text or
| instantly and visually applying the same edit on multiple
| similar lines.
| tekawade wrote:
| Lookup helix tutorial. It's pretty useful.
| Iridescent_ wrote:
| Kakoune has replaced many features with multicursor, including
| the sed-like commands (where you just select an area, search
| for patterns inside it to create the multiple cursors, then
| perform regular edits (which also means you can perform much
| more complex than simple replaces). It is really useful for
| refactors, e.g. even if you don't have any LSP (e.g. for plain
| text) you can easily rename symbols, reorder/select in log
| files, etc
| w4rh4wk5 wrote:
| Multi cursor support in VSCode replaced 98% of my need for
| macros. Yes, macros are more powerful, but they are pretty easy
| to get wrong. With multiple cursors, it's far easier to spot
| where your inputs don't work out and adjust accordingly.
|
| Multi cursor is the feature that increased my productivity the
| most across the board.
| skydhash wrote:
| Proper macros are vim and emacs one. They have proper
| movement shortcut that fits both code and prose.
|
| Especially as code is formal notation, such that it's
| structured quite rigidly, macros composition can be seen as a
| meta language. Multi cursors is more suited for the "work
| hard, not smart", like preferring litteral search instead of
| learning regex.
| cassepipe wrote:
| Forget macros and multi-cursor. (Regex) substitutions from
| vim's command line replaced 98% of my editing needs and
| rendered a lot of my vim-fu useless.
|
| (Just like searching with / replaced 98% of my navigation)
|
| Editing something without having to actually place the cursor
| anywhere is a killer feature
|
| Also neovim can show you your substitutions live, no need for
| a plugin anymore. It's the default.
| cpill wrote:
| Word Bro! Regex is so simple to read and easy to get
| right... and its like if Immanuel Kant wrote find and
| replace, yeah, learn a new language to do a single
| function... yEAH! 98% Bro! I'd marry Regex if I could (but
| if we got divorced it would be my exregex [which is almost
| a palindrome!] Bro!)
| mayli wrote:
| Bro, not every guy/girl is a regex master, multi-cursor is
| a much better UI/UX wysiwyg editor for everyday users.
| latexr wrote:
| Without meaning to sound like the "friendship ended" meme, I
| was a heavy user of macros in vim and neovim. It was probably
| my favourite feature. After I switched to Helix, I began
| using multiple cursors and now those are my favourite
| feature, I barely use macros anymore. Being able to see your
| movements live and intelligently using multiple clipboard is
| not just powerful, it's fun too and rewards well-designed
| code.
| themadsens wrote:
| Whats with all the fuss over multicursor. How is this different
| from just using '.'
| wilkystyle wrote:
| dot repeat is the wrong comparison. A closer one would be
| macros, but even then a good multiple cursors implementation
| is often faster, more intuitive, and requires less cognitive
| overhead. One of the better examples of the usefulness of
| multiple cursors is from Emacs Rocks (link goes to 0:23):
|
| https://m.youtube.com/watch?v=jNa3axo40qM&t=23s
| camgunz wrote:
| What do you when the things you want to change don't all
| fit on the screen at once?
| luxurytent wrote:
| You do a search/replace which has a similar function,
| although applied differently.
| wilkystyle wrote:
| At least in e.g. Emacs and sublime text, you can mark all
| occurrences throughout the entire file. Assuming the
| matches are similar enough that the same motions apply
| even if you can't see the cursor, you can perform those
| operations.
|
| Otherwise, as a sibling comment said, incremental
| search/replace is your friend.
| eviks wrote:
| You'd do text editing with it with the coolest feedback loop -
| immediately seeing the changes and what those changes apply to
| beforehand, that's different from having to repeat some macro
| multiple times
| dizhn wrote:
| Highlighted search/replace does this pretty well too.
| andrepd wrote:
| Multiple cursors were the killer feature that got me to start
| using Sublime Text back in ~2010. Still an absolute staple of
| my text editing toolbox. Ctrl-D Ctrl-D Ctrl-D ...
| qiine wrote:
| "Image API: vim.ui.img"
|
| Oh neat!
| natas wrote:
| one cursor for you one cursor for claude code :)
| luxurytent wrote:
| LLMs: Look, I can write code! neovim users: hold my beer,
| multicursor is here!
| alwillis wrote:
| Looking forward to multiple cursors... but Vim/Neovim can
| already do some of the common use-cases for multiple cursors,
| like prepending (or appending) text to a bunch of lines using
| visual block mode [1].
|
| Here's a video example [2]:
|
| [1]: https://neovim.io/doc/user/usr_10/#_visual-block-mode
|
| [2]:
| https://www.reddit.com/r/vim/comments/jai57c/the_usefulness_...
| semiinfinitely wrote:
| the zig build system is the only thing that actually matters in
| these notes. nobody maintains a parallel build system for fun--
| it's a clear signal they're finally pathfinding a way to migrate
| the core away from legacy c. zig's native interop is basically
| the only way to do this incrementally without the massive
| friction of a full rust rewrite. definitely makes nvim feel like
| a much more serious environment for systems-level performance
| work.
| mihaelm wrote:
| It doesn't necessarily mean they're going to migrate from C,
| building a C project is just so much nicer with Zig than
| fiddling around with CMake. You got people using it as a build
| system even for Go projects, especially if they're relying on
| CGo.
|
| However, if you were entertaining the idea of slowly switching
| to Zig, the build system would be the place to start. Moving
| away from CMake is worth it even if you don't push it further.
|
| But yeah, the C-Zig interop story is so good it's a no brainer
| if you want to "modernize" your C codebase, and you can do so
| incrementally instead of stopping the world for a rewrite.
| tovej wrote:
| Couldn't disagree more. Why move away from solid, mature build
| systems to something relatively fringe like zig.
|
| Sadly, this is the general trend with neovim in general: less
| focus on stability, more and more focus on shiny new things. If
| I didn't have an nvim config that I'm used to I would have
| switched to plain vim ages ago.
| metaltyphoon wrote:
| > the only way to do this incrementally without the massive
| friction of a full rust rewrite
|
| Any rewrite is massive friction, I'm sure probably meant port?
| The only annoyance with Rust ports is if you have to support
| varargs. Hopefully that will come to an end soon.
| toisanji wrote:
| Is anyone using them vim with Claude or any of these coding
| tools? I want to, but I haven't found a good workflow.
| OliverWich wrote:
| Sidekick.nvim is nice, you get a "real" terminal window on the
| side with many different agents to choose from.
|
| Either opencode, claude, gemini, copilot, basically most that
| are relevant :D
|
| Its a pretty light connection-layer, so it helps with sending
| context.
| thayne wrote:
| FWIW, it's also made by Folke, the same developer who made
| lazy.nvim and snacks.nvim, as well as some other high-quality
| plugins.
| lachlan_gray wrote:
| Mentioned elsewhere, but
|
| :term claude
|
| In a split goes a long way for me!
| Zizizizz wrote:
| Yes tab split, neovim on the left, companion on the right, or
| different tabs. The plugin codecompanion.nvim is also great. I
| use it for common tasks. Like:
|
| vaf (visual around function) <space>ad (leader key add
| docstring).
|
| And it documents the functions with my system prompt
| instructions for what good docstings should look like.
| mathieudombrock wrote:
| CodeCompanion.nvim is a pretty nice plugin. I use that for
| quick stuff and opencode in the embedded terminal for larger
| tasks.
| altermetax wrote:
| Just open a terminal split/tab and use claude there. The neovim
| buffer will update real-time.
| kelnos wrote:
| I just have vim open in one terminal tab and Claude Code open
| in another terminal tab. Works great.
| jauntywundrkind wrote:
| I've been loving NeoVim with AstroNvim so much. I'd done some
| editor configuration and it felt daunting and mostly just...
| didn't. And I was not good about using the leader key, because of
| tmux to zellij problems, that nothing was discoverable (zellij
| adds visual overlays to guide you through usage, unlike tmux's
| memorize everything approach). AstroNvim has changed both of
| these so much for me: there's excellent community packs
| (https://github.com/AstroNvim/astrocommunity) that are easy to
| drop in that have good configuration out of the box for
| everything you could want to do, and the leader key has a
| wonderful little bottom-of-screen UI for itself that helps you
| discover what's available (that astronvim plugins naturally
| grow/augment).
|
| On Neovim, very exciting and interesting to see 0.12.0. It'll be
| interesting to see if folks really do migrating and at what speed
| to the new built-in plugin system. There's still dozens of other
| still used plugin systems, but LazyVim seems to have really
| cemented itself as the lead (and is used in AstroNvim). It feels
| like vim-pack is trying to be lighter still. Will it work? Will
| it get adopted? Will be neat to see. PR for vim-pack:
| https://github.com/neovim/neovim/pull/34009
|
| Last, I still dream of a day where neovim headless is capable of
| running multiple different clients at once. The rpc architecture
| is so powerful and so amazing. But we're still (afaik) anchored
| to having once canonical screen, where-as I want to be able to
| have multiple editors, looking at different views of the
| workspace, with different layouts, and specialty windows like IDE
| debuggers in their own layouts. It's hard to dream of neovim
| disaggregating itself, blowing up the screen.c, but maybe maybe
| maybe maybe some decade, possibly, I hope.
| shmerl wrote:
| Congrats on diff mode improvements. Hopefully forge style
| highlighting mode for two way diffs will be available next.
| nickandbro wrote:
| If anybody wants to checkout my site to learn the basics of vim.
| Here it is:
|
| https://vimgolf.ai
|
| I proxy to neovim instances for each level. Still working out
| some kinks but soon to complete it
| awesan wrote:
| Seems like you need an account just to try it.
| nickandbro wrote:
| Yeah working on a smart way to rate limit stale requests for
| those who don't have accounts.But the final version will
| allow anybody who is not a bot, to get into a vim instance
| without logging in. Thanks for the feedback.
| imjonse wrote:
| It probably goes against Vim tradition, culture and freedom to
| choose, but I wish they added even more built-in features (like
| Helix) that are currently implemented in competing and sometimes
| brittle plugins and have to be put together into also competing
| vim starter packs and distros of plugins and config files just to
| have a modern setup out of the box.
| skydhash wrote:
| Define "modern"!
|
| Almost all such complaints are close to "I want to be cool and
| be seen as an haxor, but all I know is a bit of VSCode and
| IDEA, make it easier for me, plz".
| Sayrus wrote:
| I think what they did with first-party support for LSP would
| be an example of this.
|
| However, Neovim explicitely states that they don't want to
| turn VIM into an IDE. The feature parent is talking about
| seem to be falling into that type of vertical integration
| instead of composability.
| augusto-moura wrote:
| I believe neovim started as a fork specifically to implement
| features like LSP support and package management, VIM
| eventually also caught up. But i don't believe anything is out
| of the table, or against Vim tradition. Which features do you
| want to see built-in, specifically?
| QuantumNomad_ wrote:
| I'm also pretty sure that on an episode of The Standup, one
| of the Neovim core maintainers TJ DeVries (Teej) said that it
| is a good idea to prove new ideas in the form of a plugin
| rather than submitting pull requests for Neovim itself with
| new ideas that have not yet been tested out and proven in the
| real world. Implicitly implying that indeed Neovim is open to
| bring features from plugins into core Neovim itself, if they
| are proven to be useful for a lot of people.
|
| Unfortunately I don't remember what episode it was or even if
| it was specifically on an episode of The Standup, or if it
| was some other video that he and ThePrimagen did outside of
| The Standup.
| aidos wrote:
| Multi threading, but yeah.
|
| Original HN post here if you're interested.
| https://news.ycombinator.com/item?id=7279358
| lawn wrote:
| Neovim is actively moving in that direction.
| gorjusborg wrote:
| I agree in principle that absorbing the best from the ecosystem
| is good. However, anything pulled into core should have a long
| lifetime and be considered part of the API. This deserves
| careful consideration, and plugins work really well until it is
| clear there is a reason to pull something in.
| Blackthorn wrote:
| Not to talk about the other side of the holy war too much,
| but one of the things I appreciate about GNU ELPA is it's
| treated as part of the Emacs distribution and needs to follow
| all the rules of Emacs proper as a result.
| bheadmaster wrote:
| This is what happened with the Language Server Protocol.
|
| Prior to 0.9 (if I recall correctly), you had to install a
| plugin to be able to interface with LSP servers, and in 0.9
| they integrated the support into NeoVim itself.
| shmerl wrote:
| Would be nice to also have such support for DAP, though nvim-
| dap is doing a good job so far.
| butterlesstoast wrote:
| With all the supply chain attacks this last week, little hesitant
| to upgrade.
| 0x696C6961 wrote:
| The built-in incremental ast based visual selection is nice.
| nixpulvis wrote:
| My #1 issue with Neovim is the new ! Behavior. Anyone know how to
| make it toggle the alt terminal screen and just output to the
| primary screen like it does in Vim?
| throw567643u8 wrote:
| With its own package manager now, and LSP library, you really
| don't need a lot of config tweaking for a minimal vim setup these
| days.
___________________________________________________________________
(page generated 2026-03-29 23:00 UTC)