Rendered at 19:57:24 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
himata4113 19 hours ago [-]
I swapped to neovim and never looked back. I don't even have vscode, jetbrains or anything similar installed anymore.
AI has made it so so easy to get into neovim and make anything work no matter how obscure it is.
The biggest benefit for me which I haven't realized how good it is with tmux and the low low memory usage. I mean I can keep EVERY project I work on open, quickly switch and maintain.
No more 10gb memory usage on a SINGLE project, no more laggy remote access, no more dreading reboots, no more wasting time.
Kernel panic? everything is right there how you left it, honestly it makes me feel so sad because the poor design of IDE's have been such a show-stopper for a LOT of good project designs that I have completely avoided due to introduced complexities that come not to mention how slow things can become.
Now I can just ssh into my pc from a laptop and work, no synchronization, no need to have a beefy laptop and incredible battery life.
Agentlien 16 hours ago [-]
I've been using Vim daily for 13 years and switched to NeoVim about a year of two ago. For me the main advantages over Vim are just the Lua scripting instead of Vimscript, its support for language servers, and better handling of terminals windows running inside Vim.
However, I do still run visual studio in parallel for debugging. It's basically essential when dealing with console game development.
liancheng 3 hours ago [-]
I found DAP neat enough for interactive debugging (when logging is not enough). But I only used DAP under Neovim to debug Python.
himata4113 15 hours ago [-]
I just let AI handle any and all debugging at this point, haven't had an issue where AI couldn't find out what the problem was, finding a solution on the other hand is a hit or miss still.
beAbU 5 hours ago [-]
Can AI pause execution and step through the code line by line? Because that's what I think your parent comment is referring to.
goosejuice 5 hours ago [-]
AI can use gdb.
thayne 1 hours ago [-]
What plugins do you use for AI in neovim?
KetoManx64 55 minutes ago [-]
Not OP, but I don't have use AI within neovim itself, but you can use AI tools to learn and configure neovim to fit your needs.
magguzu 19 hours ago [-]
I use neovim daily but am 100% sure I'm not even scratching the surface of its power. In fact I'm not even sure I'm using anything specific to the "neo" variant vs plain vim.
I can do simple search/replace, page up/down, jump to character or delete x words, but I feel like I'm missing a lot to really take advantage of it.
Is there a tutorial or guide people recommend to become more of a power user? The only plugin I have is the Markdown editor for instance.
jackrickards 15 hours ago [-]
I'd recommend checking out lazyvim, it comes with a bunch of very sensible plugins and you can read through the lazyvim docs (and then click through to individual plugin docs) to discover them and see which ones you want to use.
fingerlocks 14 hours ago [-]
I recently switched to LazyVim and the default config in their tutorial included all the “extras”. It transformed vim into some kind of hallucinogenic kaleidoscope of an IDE with all sorts of telescoping overlays and pop-ups with a color scheme that fits well with an 8 year old girl’s princess themed birthday party. I actually screamed a little.
Not sensible. completely insane.
himata4113 14 hours ago [-]
Not sure about the "tutorial", but I use lazyvim as base for LSPs, snacks, neo-tree and a theme matching the rest of my desktop and it seems to be fine?
nvim has a lot of "fun" plugins that you wouldn't actually use so I think you might have ran into that.
deafpolygon 9 hours ago [-]
there’s the LazyVim distro and the lazy.nvim plugin on which it was built. the latter is a bit more sensible.
Just to add, there are so many hour long Neovim setup videos on youtube that will make your life easier
rigmarole 3 hours ago [-]
Drew Neil‘s books, Practical Vim and Modern Vim are excellent.
troyvit 16 hours ago [-]
If you search up vim games you'll find some fun tutorials.
himata4113 17 hours ago [-]
Honestly, same. I did naturally start to pick up things such as c(code actions) and some git related helpers. But <cnt><c/d/n/o/y/p> gets you 90% of the way there with / navigation.
Also just use the mouse! Lazyvim has great support for it.
<leader>SK is your friend as well.
rluiten 14 hours ago [-]
Remember that `<leader>SK` does not show neovim built ins.
Example ctrl-o which moves to older jumplist position is not show in it.
I'd also suggest kickstart.nvim over Lazyvim as its leaner with a primary file for configuration it is not lacking power.
liancheng 3 hours ago [-]
Unfortunately kickstart.nvim is no longer actively maintained.
cudder 8 hours ago [-]
> Also just use the mouse! Lazyvim has great support for it.
My mileage was quite different: last time I tried, scrolling too fast with the mouse wheel consistently caused a segfault.
dgsii 15 hours ago [-]
You _can_ just use a mouse, but I would not recommend it for someone who wants to learn to become a power user.
I feel like the habit I’ve benefited the most from on my neovim journey has been reaching for :h before doing any web search. Good completion in the command-line helps a lot there.
pcael 8 hours ago [-]
What do you use for managing several different projects in nvim?
ray_v 18 hours ago [-]
Ok, this sounds awesome, but do you miss the GUI integrations? like , being able to pop a document open in your editor from the desktop?
It just feels like it's hard to nail down your preferred workflow / setup ... but it's likely worth it if you're using it daily!
Are there any good visual or video demos of using this type of setup? I'm having trouble picturing what makes people really love this type of TUI-only workflow.
chrysoprace 17 hours ago [-]
It's not my kind of workflow but you can download a graphical client like Neovide, which I think has options for opening directly from your file browser.
I typically have a terminal-heavy workflow so it's very rare that I'm browsing to files from within my desktop, but if I am using Dolphin to look for a file I have a "Open terminal here" shortcut and then I'll usually just run "nvim doc.md".
Why not give it a try? You'll likely find that there's an adjustment period and you can always switch back to your old editor if you don't like it. The beauty of it is that you can build it into whatever IDE you want instead of having useless features shoved into your IDE whether you use them or not.
jrumbut 17 hours ago [-]
As an aside, it would be straightforward to make vim/neovim the editor that opens when you double click a text file on the desktop.
This kind of setup is at its most powerful when you live on the command line though. For instance, you need to modify .py files across multiple projects that mention a certain variable, have a certain word in their name, and were modified within the last month.
That search is a bit easier in bash/zsh than it is in most IDEs and the strength of vim/neovim is the shell integration.
liancheng 3 hours ago [-]
In Neovim, most non-toy language servers allow you to open the doc/definition in a popup/floating window, typically bound to `K`. Some language servers like rust-analyzer and gopls also support opening the docs in your browser.
hboon 7 hours ago [-]
> like , being able to pop a document open in your editor from the desktop?
There's a hackish way to do it by watching for Neovim command line commands that start with "/Users/" (change it if you are on other OS).
Your coding agent can probably hack something up based on:
`//Hackish supports drag and drop files into Neovim by examining when command line starts with "/Users/".`
jonaustin 17 hours ago [-]
You're holding it wrong if you're dragging files around a desktop to open them.
Just use a fuzzy file finder within the terminal or within vim itself.
himata4113 17 hours ago [-]
lazyvim DOES have mouse and GUI-type support. This is a huge myth! I use mouse regulary in neovim and tmux.
skydhash 17 hours ago [-]
I use Emacs and opening a new file is just pressing “C-x C-f” (find-file), typing the path (completion is available), and pressing enter. As for vim, I would spawn a new terminal (WM keybind, new tab, new pane with tmux), cd to the directory and open it with vim.
The nice thing is that I rely only on the keyboard, no need to point with the mouse. It may not be faster, but typing is sequential and there’s no context switching. So muscle memory helps a lot. Just like you don’t think about each character when you write, I don’t really think about the shortcuts and commands I use.
opan 2 hours ago [-]
It's interesting that vim and emacs have this sort of cultural difference where emacs users tend to have one session always open, and vim users are more likely to directly launch a new session per file. I've largely adopted the emacs approach with my usage of neovim, though still use a mix. I have a Session.vim file that opens my windows/tabs/buffers I saved, including remote files using the scp://hostname/filepath syntax. Certain files I edit often enough that I just want them always open, and arranged a particular way. I do sometimes open a one-off separate session to quickly edit a config, though. I don't wanna mess up my muscle memory by introducing too many extra buffers or possibly messing up the order (although if I did do that I could just quit out and reopen the Session.vim file to get back to my saved arrangement).
Another thing I picked up from my time with emacs was making keybinds to interact with the "other" window. One macro I use often will delete the second line of the file in my current window, save, change to the other window, delete second line, save, change back to original window. When activated from keybind it all happens approximately instantly. I also have some binds to jump to the top of the other window's file (without leaving my cursor stuck over there) and so on, letting me keep my cursor in the main area most of the time.
skydhash 1 hours ago [-]
Vim current directory is tied to the process, while each buffer in Emacs have its own default directory.
Also the buffer’s local variable in vim comes from different sources. In emacs, a lot of stuff are tied to a major or minor mode. You only have to toggle them to switch between keybinds, syntax,…
smohare 3 hours ago [-]
[dead]
gootz 17 hours ago [-]
Sounds awesome. Can you tell us more... How do you ideally use/setup AI,tmux and nvim?
himata4113 16 hours ago [-]
tmux+lazyvim with mouse enabled, tmux with continiuum/resurrect, rest I can't really tell you about other than telling AI exactly what I wanted and doing so until I felt productive again.
ai is an independent tmux window where I can shuffle between project groups.
for AI I found oh-my-pi from can1357 it's magical how good it is. It was a top rated post on HN awhile back.
gootz 8 hours ago [-]
Awesome! I'll give it a shot. Thank you!
0x1ceb00da 16 hours ago [-]
How many weird terminal bugs do you have in your setup? Eg one that annoys me the most is that pressing esc in insert mode often takes a few seconds to do its thing.
hdra 16 hours ago [-]
any chance you have a key sequence mapping that starts with esc? sounds like its waiting to see if you are gonna be pressing another key before timing out and do its thing
0x1ceb00da 16 hours ago [-]
It happens randomly, which makes me think it's a bug.
xeyownt 12 hours ago [-]
Unlikely. Start with empty configuration, and try to reproduce first.
smohare 3 hours ago [-]
[dead]
skydhash 8 hours ago [-]
It’s not a bug. The wait times is because the terminal supports escapes codes (which start with an escape character). So most TUI (which put the terminal into a special mode) have a wait time to distinguish between the two (because for the terminal there’s no difference between keyboard events and the software UI). I think it’s configurable in both tmux and vim.
himata4113 14 hours ago [-]
Never had that.
syngrog66 14 hours ago [-]
vi/vim has enabled that for 30+ years.
jatora 19 hours ago [-]
Use windows and leave kernel panics behind :)
i can tell you dont actually SSH often by tbe way. Also, tmux doesnt magically reduce resource requirements of your applications
himata4113 17 hours ago [-]
What are you talking about, kernel panics are part of life with consumer hardware. They would happen even if it was windows?
You're right. I don't use SSH that often due to kubernetes, infact I only use ssh for connecting to my desktop to access my tmux sessions and it's great. I know where you're trying to go with this and it's simply not true.
Who said anything about tmux? We're talking about neovim which is extremely light weight and the LSP's don't sit around being active all the time. They have a set duration where they terminate when unused which is simply not possible in most IDE's (LSP based ones are OK, but have problems reconnecting).
Agentlien 16 hours ago [-]
> kernel panics are part of life with consumer hardware.
This isn't right. It was certainly true in the nineties, but I haven't seen one in years on Windows and I spend many hours a day in it both for work and play.
himata4113 15 hours ago [-]
DDR5 where yields are pushed with module level ECC? Janky amd gpu drivers, "RGB" controller drivers misbehaving, some hardware that is just as bad as it was in the 90's since they all use driver sourcecode copied from the 90s.
jatora 17 hours ago [-]
you mentioned tmux. are you gaslighting me? lmao.
and kernel panics are exceedingly rare on windows. i havent BSOD'd in eons
3836293648 9 hours ago [-]
Kernel panics are almost entirely about bad RAM on all systems today. But last time I was stuck on Windows, about 2017ish, I was suffering constantly from blue screens in a way that never triggered on linux.
himata4113 16 hours ago [-]
yes I mentioned tmux as a project management/switcher tool what about it? (how good (nvim) is with tmux and the low low memory usage.
I haven't had a kernel panic once on reliable hardware. Linux is way more stable than windows device drivers and progressively less reliable graphics drivers.
jatora 13 hours ago [-]
"Who said anything about tmux?"
"yes I mentioned tmux as"
lol. good day
imjonse 1 days ago [-]
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.
gorjusborg 23 hours ago [-]
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 22 hours ago [-]
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.
qudat 19 hours ago [-]
There is zero reason not to include a picker like helix does. I’m gonna guess 90% of everyone running neovim has a picker
gorjusborg 7 hours ago [-]
I believe we are thinking about different time horizons, and your language and comparison to <modern editor> reveals a lot about unsaid about your reasoning.
I don't think comparison to other editors is a good basis for deciding what should be pulled in. The vi ecosystem was and remains weird to those outside, but in a way that is internally consistent to the usage patterns of its own user over decades.
Also, percentage of users using X feature is also a bad selection criteria for pulling a plugin provided feature, unless that number is 100% and there is little deviation in configuring it. There is very little friction in pulling in a plugin as a user.
So what are some good criteria for absorbing plugin functionality?
- extensions that provide an API for entire ecosystems (plenary, lazy.nvim)
- plugins that add missing features or concepts that are to useful, and timeless to ignore
- plugins that would benefit themselves or neovim by moving to native code
Honestly, the bar for absorbing plugins should be pretty high. There should be a real benefit that outweighs the cost of more maintenance, coupling, and ultimately cost.
The cost of installing plugins is pretty low, and they are great at keeping the core software simple.
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 22 hours ago [-]
Would be nice to also have such support for DAP, though nvim-dap is doing a good job so far.
augusto-moura 1 days ago [-]
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_ 23 hours ago [-]
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.
GCUMstlyHarmls 19 hours ago [-]
This is essentially how the new package manager got done. `mini.deps` was created as basically a proposal for a built in package manager (beyond also just being its own thing), sat in the wild for a year or two then a derived version got imported.
I've always wondered what this legend is doing now
bulbar 15 hours ago [-]
That's why I stopped using it. Didn't want to have "reconfiguring an editor to be an IDE" as a hobby.
jrop 16 hours ago [-]
As others have said, the fact that they're letting the ecosystem settle before including something out-of-the box is beneficial in some sense. It's allowed time for experiments (including my own "how would I do UI in Neovim: morph.nvim [1]").
For some, this stage of a project attracts tinkerers and builders, and lets the community shape how things are done in the future. It's not always practical, but it does have a certain appeal.
Which is why I just went with Helix and learned their keybindings. I have much more important things to do than figuring out why a plugin stopped working.
eviks 15 hours ago [-]
Doesn't seem like it if you can waste time learning all the keybinds just because you switched an editor, but also how does "can't do things since there are no plugins yet" rank higher vs "sometimes stops working" in importance?
g947o 8 hours ago [-]
It took me about 10 min to learn the keybindings. It does take longer to get familiar and efficient with them, but I wasn't a Vim master to begin with. (I can navigate efficiently and am proficient with a few combinations that I use the most, but that's about it.)
> "can't do things since there are no plugins yet"
Depending on what I am doing, I will probably go back to VSCode to get things done. Terminal editors are nice, but VSCode's extension ecosystem and usability is unmatched. I speak of that as someone who has spent hundreds of hours developing VSCode extensions. For me, "can't do things" is not (necessarily) a reason to set up Neovim plugins. It means I should figure out 1) if that's something I need to do regularly 2) If so, what's the best way to get it done.
(I am very well aware of what you can do with vim/Neovim plugins, just like zsh and tmux etc. Not spending time hand writing my config or setting up my plugins is an intentional choice. I like to start with a commonly used setup, discover pain points and bottlenecks, and then optimize or find some other solutions.)
goosejuice 5 hours ago [-]
No-one started as a vim master.
Your arguments here are valid, for a particular kind of person who values a particular kind of workflow.
Some of us would rather use vi than vscode. If you take away the plugin ecosystem, the core value is still there.
ratrace 8 hours ago [-]
[dead]
goosejuice 17 hours ago [-]
Just pin the plugin or don't use it.
g947o 17 hours ago [-]
Not a choice if you need a specific new feature or a certain fix.
The entire software development world would be much simpler if nobody needs new features, bugs and CVEs don't exist, or "just pin the version" works.
jatins 16 hours ago [-]
There are lot of readymade neovim configs you can copy. I was experimenting recently with lazy.vim and took a git clone and cp command to get up and running
red_hare 14 hours ago [-]
I love the batteries included in Helix. Just the right amount that I don't need much else.
At this point I just want a decent Helix-Evil-Mode.
eviks 15 hours ago [-]
But this isn't vim, so doesn't go against those?
> 0.13 “The year of Batteries Included”
> 0.12 “The year of Nvim OOTB”
imjonse 15 hours ago [-]
nice to see that.
lawn 24 hours ago [-]
Neovim is actively moving in that direction.
skydhash 1 days ago [-]
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 24 hours ago [-]
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.
helterskelter 1 days ago [-]
Up next for 0.13: multiple cursors! I have no idea what I'd do with this feature but it sounds intriguing.
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.
cassepipe 23 hours ago [-]
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.
Agentlien 15 hours ago [-]
Regex search and replace is definitely among my most used features and the preview in NeoVim is amazing
That said, I do find myself using recursive macros quite often. They're an easy way to make a set of random little changes which would be hard to put into a solid regex. Especially when filtering and formatting logs to produce a list of error messages on a condensed format for review. It doesn't happen as often, but I also find them incredible when doing more complex substitution across a project.
bee_rider 20 hours ago [-]
1) is there a reason both of the other responses to your comment are all full of Bro’s? It this an in-joke?
2) Regex is great, and vim is a good place to exercise the “try a regex” reflex. And on the regular old bash command line, it is great for making stuff like locate more precise.
mayli 21 hours ago [-]
Bro, not every guy/girl is a regex master, multi-cursor is a much better UI/UX wysiwyg editor for everyday users.
cassepipe 7 hours ago [-]
Sis, substitutions started being useful being I even learned Regex and I have done an incredible amount of edits with the just the bare minimum of Regex knowledge
shimman 18 hours ago [-]
Terminal editors are not WSIWYG applications. I don't think multi-cursor is the correct for a vim motion workflow but I'll admit my vim-fu is not as strong but I get by with the substitute command + grep good enough where I rarely feel the need for a GUI editor to use multi-cursor.
Since VS Code is already an inefficient way to move around a code base, I don't think we should take any lessons seriously outside of how useful the LSP protocol become for adoption.
ablob 14 hours ago [-]
I think multi-cursors can be seen as an extension of macros, just that instead of defining the macro and navigating to the relevant places you instead navigate first and then execute the commands interactively (in essence skipping the part where you have to record). As a side effect you also don't need to be that concerned about what to do after having made a mistake.
I've had some pretty nasty string-wrangling with the substitute command that could've been avoided by just using a macro and the other way around. I'd argue these things complement each other and there is no need to restrict yourself arbitrarily.
Having it and not using it is better than needing and not having.
I can recall countless times where multi-cursor would've been just the sweet-spot I needed.
P.S.: multi-cursor is not about moving around the code base and therefore not taking lessons about navigation has no impact in this matter.
22 hours ago [-]
cpill 21 hours ago [-]
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!)
latexr 22 hours ago [-]
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.
skydhash 24 hours ago [-]
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.
Iridescent_ 1 days ago [-]
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
alwillis 22 hours ago [-]
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].
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 1 days ago [-]
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.
steve_adams_86 1 days ago [-]
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
runevault 1 days ago [-]
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.
wredcoll 22 hours ago [-]
How do you place the cursors then?
hiccuphippo 21 hours ago [-]
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.
skydhash 24 hours ago [-]
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)
thiht 22 hours ago [-]
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.
bluecalm 1 days ago [-]
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.
eviks 1 days ago [-]
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 23 hours ago [-]
Highlighted search/replace does this pretty well too.
eviks 16 hours ago [-]
Not really, it only does it for the first edit, while multiple cursors offer continuous feedback for all further besides, search/replace has extra toolbar and usually can't as easily select, for example, "current Identifier under cursor" if those are different, so it's worse before the first edit as well
dizhn 11 hours ago [-]
I'll have to try that out sometime. Never used multiple cursors. However, search/replace with vim/neovim isn't just the first edit either. It highlights all matches and shows you the proposed changes as you type as well. (It is probably a configurable thing).
eviks 11 hours ago [-]
How can it show proposed changes if search doesn't match anymore after edits?
You search for OLD, replace it with NWE, then notice the typo, delete 2 chars and type EW. How can search and replace help you here without searching for NWE anew?
Yeah, do try it out to at least see the difference
dizhn 10 hours ago [-]
I am not saying it's better or you shouldn't use multiple cursors. It does help a lot as opposed to the old way of not seeing what would have been changed.
How does multiple cursors work anyway? How do you place them? By search? Is it used for anything other than working on matching text?
eviks 8 hours ago [-]
Your place them via search, manual click, extending up/down the line, via "match current word"
And it's also used for new text entry, not just editing matching text, e.g., add an extra field to each of these 5 arrays
dizhn 8 hours ago [-]
I can picture it better now. Thanks.
meekins 1 days ago [-]
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.
themadsens 1 days ago [-]
Whats with all the fuss over multicursor. How is this different from just using '.'
wilkystyle 1 days ago [-]
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):
The dot command, as you probably well know, is a macro that captures the last change: was it '3cw' or 'cE' or '7s' or <visual>s or 'ct)', all changed to the last insert. All intuitively without you even having to think about it.
Much more powerful than "change all my selections to the next input" IMO.
camgunz 24 hours ago [-]
What do you when the things you want to change don't all fit on the screen at once?
eviks 16 hours ago [-]
That's one challenge I haven't seen editors tackle correctly by, e.g. having some special condensed view where only lined with cursors are shown so you can see more cursors on the screen and easier scroll around to see even more skipping the rest of the text (like some git diff tools do, showing only diffs with minimal context)
So you either cycle through cursors (if your editor has a concept of "primary cursor") to see before/after or you do it blindly and accept a chance to be wrong
wilkystyle 22 hours ago [-]
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.
luxurytent 22 hours ago [-]
You do a search/replace which has a similar function, although applied differently.
andrepd 1 days ago [-]
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 24 hours ago [-]
"Image API: vim.ui.img"
Oh neat!
keyle 20 hours ago [-]
Any chance regular vim will some day get multiple cursors? That's the one thing I miss.
willrshansen 17 hours ago [-]
Helix editor is based around that. Better than vim default imo
tekawade 1 days ago [-]
Lookup helix tutorial. It’s pretty useful.
natas 23 hours ago [-]
one cursor for you one cursor for claude code :)
scuff3d 1 days ago [-]
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.
luxurytent 22 hours ago [-]
LLMs: Look, I can write code!
neovim users: hold my beer, multicursor is here!
meszmate 10 hours ago [-]
At this point my dev setup is basically just Neovim, tmux, and a terminal. I ended up removing the usual IDEs because I just was not opening them anymore.
What sold me was not even the editor itself at first, it was the workflow. I can leave sessions running, bounce between projects instantly, and my system still feels light. That matters a lot once you get used to having multiple things going at the same time.
Claude Code also helps a lot with the rough edges. When I run into some niche config issue or weird tooling problem, it is usually fixable in minutes instead of turning into a rabbit hole.
sdsd 16 hours ago [-]
My favorite thing about Neovim is how easy it is to customize (I know, I know, but keep reading, it's about to get spicier) with LLMs. I got sick of Bear and Obsidian and had DeepSeek bash Vim's head in until it was the todo + calendar app of my dreams. Since OpenCode can easily interact with Vim during the terminal, it can itself test whether its changes work until it meets the criteria I set. No going back.
maleldil 17 hours ago [-]
Upgrading from 0.11 was relatively painless, except for nvim-treesitter, which pretty much became a new plugin. The previous version lives in the master branch, but doesn't support 0.12 at all, so you need to use the main branch when updating.
Most of the previous features are replicable with new code, except for incremental selection. treesitter-modules[1] serves as a good bridge between old and new APIs.
Incremental selection is available by default in Nvim 0.12, see `:help v_in`.
maleldil 3 hours ago [-]
Yes, I found out about that after my comment. It's a little unfortunate that I need to remap `van` itself instead of a function/command, but it works, and there's a PR to expose the function publicly.
Note that this might conflict with some text-object plugins, such as mini.ai, which define an/in by default.
benrutter 1 days ago [-]
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?
suby 1 days ago [-]
There is a roadmap and github issue tracking what is needed for 1.0.
I don't really get the point of this. If the 0 never changes to anything else, then effectively it serves no purpose and shouldn't exist. Some people even refer to software that way. Sometimes something like React 0.82 might be just called "React 82", and effectively it's 82.X in practice.
saint_yossarian 1 days ago [-]
AFAIK it's mostly about stabilizing the RPC API and Lua stdlib:
What are referring to, out of interest? Does this apply just to nvim, or vim as well?
PhilipRoman 1 days ago [-]
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 1 days ago [-]
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.
nixpulvis 17 hours ago [-]
Preach! I tried to point this out in the Neovim discord once and was basically told to pound sand. Very frustrating.
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
pawelgrzybek 1 days ago [-]
Have a look here. This is incredible guide to the `vim.pack`.
Yes, I basically gave my vim config along with this blog to Claude and it figured out 95% stuff on its own.
c-hendricks 1 days ago [-]
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`).
flexagoon 1 days ago [-]
> 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 1 days ago [-]
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.
NekkoDroid 8 hours ago [-]
Nobody said they are 1-to-1 compatible. Also, ideally lazy loading should happen on the plugin side instead of putting it on every user to configure, since neovim natively basically has everything needed for plugins to do the lazy loading of heavy parts[1] and if something is missing it probably is better to add it the hooks for it upstream in neovim instead of the plugin manager so it also works for personal config/plugins.
Yes, my point was that it's probably more verbose because it doesn't have the same feature set
NekkoDroid 7 hours ago [-]
I guess yeah, on me for missing that implication.
But as indicated by my comment in the specific case for lazy loading, the plugin manager is the wrong place to have it. Regarding its other features I am not sure most of them need to be part of the plugin manager either (at least from the "plugin spec" part) and are better suited as extensions to other parts of core neovim (e.g. options for plugins might need better `vim.{o,g}` support for nested objects, unsure). Maybe specifying nested dependencies might make sense to add to `vim.pack`.
All this to say: yea, now it is more verbose, but it doesn't have to be.
PhilipRoman 1 days ago [-]
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?
alwillis 21 hours ago [-]
> 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.
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.
skydhash 17 hours ago [-]
Lazyloading is already present in Vim, it’s called autoload and most plugins I’ve seen use that feature
It being built in sounds nice, although I have some lines in my config that automatically install lazy if it’s missing.
tekawade 1 days ago [-]
Tried to switch but found lazy.nvim better
toisanji 1 days ago [-]
Is anyone using them vim with Claude or any of these coding tools? I want to, but I haven’t found a good workflow.
nzach 3 hours ago [-]
What I do is use 'C-z' and 'fg' to suspend and resume my editor when I need.
Pressing C-z on neovim puts me back in the terminal so I can do whatever I need to do and when that is done I just type 'fg' in the terminal and it opens up my neovim again, exactly as it was.
OliverWich 1 days ago [-]
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 1 days ago [-]
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.
mkozlows 18 hours ago [-]
I just run them in separate terminals. The only real gap was that I couldn't tell the robot to open files in nvim when I wanted to look at them, the way it could in other IDEs, so I whipped up a quick skill (https://github.com/mkozlows/nvim-skill) to do that.
mjrbrennan 15 hours ago [-]
This is why I switched to cursor over the last few months out of nvim. Just wasn't any smooth first class integrations with AI tooling. I still use vim bindings there, and I use nvim for quicker edits, but the AI editing and Cursor Tab is just way better than the AI stuff in nvim.
lachlan_gray 24 hours ago [-]
Mentioned elsewhere, but
:term claude
In a split goes a long way for me!
gkfasdfasdf 17 hours ago [-]
Ghostty split panes - coding TUI in one pane, neovim in the other, maybe a third pane for shell.
jonaustin 17 hours ago [-]
Just use this; it's literally claude code in a terminal tab in vim; also aware of what files are open in vim.
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.
altermetax 21 hours ago [-]
Just open a terminal split/tab and use claude there. The neovim buffer will update real-time.
That project is half dead now. There are commits, but has been no release in half a year, is missing major features (e.g. MCP server), and I haven't seen people talking about it for quite a while.
bluepeter 9 minutes ago [-]
Nuts to let a 42k starred project just fade away. Seems like it could really have been something. I remember being supe rimpressed w it when I installed it in its first few months.
CodeCompanion.nvim is a pretty nice plugin. I use that for quick stuff and opencode in the embedded terminal for larger tasks.
Trufa 20 hours ago [-]
Use no plugins, install Zellij (or tmux) and use in split panes, works great.
kelnos 21 hours ago [-]
I just have vim open in one terminal tab and Claude Code open in another terminal tab. Works great.
butterlesstoast 1 days ago [-]
With all the supply chain attacks this last week, little hesitant to upgrade.
suby 6 hours ago [-]
This is a valid concern imo, but I'm not too afraid about nvim itself being compromised. I do think it is risky to be depending on many plugins, which is why I'm hoping nvim can integrate more of the popular plugins into nvim proper.
throw567643u8 22 hours ago [-]
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.
0x696C6961 23 hours ago [-]
The built-in incremental ast based visual selection is nice.
c-hendricks 1 days ago [-]
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 23 hours ago [-]
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.
stryan 22 hours ago [-]
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.
It's still not super intuitive with a non-trivial config and plugins. I had enough things that hooked into LSP (Mason, linting, inlay hints, etc.) that I needed to spend a couple of weekend afternoons moving my configs over. For a lot of my config it was an all or nothing migration.
edwinmbonyjr 19 hours ago [-]
I had the same issue with LSPs. If you have LSP configurations in a dedicated lsp directory all you need to do is instead of calling this:
in lsp/emmet_ls.lua - file name is very important btw
c-hendricks 18 hours ago [-]
I may have worded that poorly. My config, specifically around LSPs was wonky. I did the old migration of configuring LSPs a while ago, but on the master branch I'd randomly get errors printed.
Update: after updating everything the errors have disappeared, phew.
nickandbro 1 days ago [-]
If anybody wants to checkout my site to learn the basics of vim. Here it is:
I proxy to neovim instances for each level. Still working out some kinks but soon to complete it
awesan 24 hours ago [-]
Seems like you need an account just to try it.
nickandbro 23 hours ago [-]
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.
nixpulvis 22 hours ago [-]
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?
konfekt 10 hours ago [-]
:Silent [0] is an effort to work similarly in Neovim to Vim's `:!`
I understand the annoyance, but my workflow for years has been running (n)vim in tmux. So I never need to run terminal commands from the editor, that’s what other tmux panes/windows are for.
CGamesPlay 20 hours ago [-]
What are you doing with ! that requires this? Some alternatives I can think of depending on the use case are ^Z or :term.
nixpulvis 17 hours ago [-]
I do a bunch of stuff with !
!make
!ps aux
Etc.
The new ! just isn't as useful, and it's harder to get back to see the outputs. The old ! Was just a drop in way quickly do something like ctrl-z command fg.
The elephant in the room is that there's nothing quite like Cursor Tab. Copilot, Supermaven, Codecompanion, etc. don't even come close. As much as I want to use Neovim full time, I just can't walk away from Cursor Tab. I can live without Cursor Agent since I can just use Claude Code when I need an agent.
Until something comparable for Neovim comes out, I just don't see how I can switch back. I would happily pay for this. I'm sure there are a lot of people in the same boat as me.
goodoldneon 17 hours ago [-]
I switched from Cursor to Neovim and at first I hated Neovim’s poor AI ghost text. Now I kind of like the break from heavy AI when I write code.
The vast vast majority of my code is written by Claude Code, so I don’t write much. But when I do it’s like an exercise in warding off programming atrophy
phplovesong 11 hours ago [-]
Most dont want that slop in their code. I have no issues with just writing the code myself. The "typing code" was never a bottleneck, and AI wont help for the real bottlenecks you have in an business setting.
shmerl 1 days ago [-]
Congrats on diff mode improvements. Hopefully forge style highlighting mode for two way diffs will be available next.
ghtbircshotbe 7 hours ago [-]
I recently hit the fold level limit, which is hard coded into Vim at 20. I was disappointed that it's the same in neovim. I tried changing the Vim code and compiling from source but apparently it's not that simple because it still doesn't work (although it does behave differently).
I'm hitting the limit due to a system that uses lists of nested rules or decision trees.
brcmthrowaway 1 days ago [-]
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?
sequin 1 days ago [-]
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.
johnsonjo 1 days ago [-]
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.
Course and book (free html, available pdf and dead tree). Covers everything I've needed concisely.
lachlan_gray 24 hours ago [-]
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!
wasabi991011 1 days ago [-]
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.
mathieudombrock 22 hours ago [-]
Vim mode in vscode is not even close to emulating a real neovim setup.
maleldil 22 hours ago [-]
OP specifically mentioned "using keyboard to navigate". If that's all you need, then VSCodeVim can get you pretty far.
alwillis 21 hours ago [-]
> you'll be pleased to know it has plenty of its own shortcuts, as well as a "VIM navigation" mode you can turn on.
For doing something quick, VS Code's Vim mode is… fine. But not if you're something serious. I often quit it in disgust and go back to Neovim.
brcmthrowaway 1 days ago [-]
What do you use?
kelnos 21 hours ago [-]
> 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`.
normie3000 1 days ago [-]
What's the FOMO caused by? Asking as a vim user starting to get FOMOOFOMO.
pl-94 1 days ago [-]
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!
NegativeLatency 1 days ago [-]
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?
aldanor 1 days ago [-]
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
tekawade 1 days ago [-]
You can use vim key binding in vs code.
shmerl 22 hours ago [-]
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.
lawn 1 days ago [-]
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.
achenet 20 hours ago [-]
If it's because VSCode has built in IDE features like LSP integration, I personally really like Helix. Keyboard based (although not the same movements as Vim/Nvim, it didn't take me long to switch), and it's got built in LSP integration/stuff just works out of the box.
Although no LLM support in the editor, I personally just run Claude Code in a separate terminal, but if you want AI in the editor you'll have to look elsewhere.
I did try Neovim with Copilot a while back, and Google shows a few NeoVim Claude Code plugins, so it's probable that if you want an LLM in your text editor, NeoVim might work :)
scuff3d 1 days ago [-]
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.
braben 1 days ago [-]
[dead]
semiinfinitely 1 days ago [-]
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 1 days ago [-]
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.
semiinfinitely 21 hours ago [-]
> slowly switching to Zig
why "slow" just re-write it with ai. and to be clear im 0% joking and am prepared to be downvoted by people who haven't yet understood how feasible this kind of thing already is and how utterly trivial it will be in the near future
metaltyphoon 1 days ago [-]
> 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.
tovej 1 days ago [-]
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.
monooso 21 hours ago [-]
I've found Neovim to be remarkably stable, even when building from main.
tovej 10 hours ago [-]
You haven't been using the LSP API then. There have also been multiple breaking changes over the last five years, including breaking compatibility with established default vim keybindings.
monooso 3 hours ago [-]
A documented breaking change does not mean the application is unstable.
The Neovim developers have been extremely clear that part of the process of getting to 1.0 is finalising the API, and that there will be breaking changes en-route.
justinmk 5 hours ago [-]
Changing default mappings is not a "breaking" change.
_bohm 6 hours ago [-]
Having spent some time with the Zig build system, I genuinely expect this development will make things less fragile than they were with the CMake build.
jauntywundrkind 1 days ago [-]
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.
semiinfinitely 1 days ago [-]
why put a built-in plugin manager. and if so why make it pack not lazy
TymekDev 1 days ago [-]
> 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.
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.
TymekDev 13 hours ago [-]
That's my impression too. However, I might give `vim.pack` a go for the novelty.
That being said, there is a way to lazy-load the plugins — Evgeni has a guide for that [1]. The "Load not during startup" variant is really simple with putting `vim.pack.add()` into `vim.schedule()`. The other myriad of options (keys, cmds, event) that lazy.nvim provides would require you to set up appropriate autocommands.
It gives me vibes of writing in Go. Everything is right there — builtin — but there's some verbosity to bear with.
AI has made it so so easy to get into neovim and make anything work no matter how obscure it is.
The biggest benefit for me which I haven't realized how good it is with tmux and the low low memory usage. I mean I can keep EVERY project I work on open, quickly switch and maintain.
No more 10gb memory usage on a SINGLE project, no more laggy remote access, no more dreading reboots, no more wasting time.
Kernel panic? everything is right there how you left it, honestly it makes me feel so sad because the poor design of IDE's have been such a show-stopper for a LOT of good project designs that I have completely avoided due to introduced complexities that come not to mention how slow things can become.
Now I can just ssh into my pc from a laptop and work, no synchronization, no need to have a beefy laptop and incredible battery life.
However, I do still run visual studio in parallel for debugging. It's basically essential when dealing with console game development.
I can do simple search/replace, page up/down, jump to character or delete x words, but I feel like I'm missing a lot to really take advantage of it.
Is there a tutorial or guide people recommend to become more of a power user? The only plugin I have is the Markdown editor for instance.
Not sensible. completely insane.
nvim has a lot of "fun" plugins that you wouldn't actually use so I think you might have ran into that.
Also just use the mouse! Lazyvim has great support for it.
<leader>SK is your friend as well.
I'd also suggest kickstart.nvim over Lazyvim as its leaner with a primary file for configuration it is not lacking power.
My mileage was quite different: last time I tried, scrolling too fast with the mouse wheel consistently caused a segfault.
I feel like the habit I’ve benefited the most from on my neovim journey has been reaching for :h before doing any web search. Good completion in the command-line helps a lot there.
It just feels like it's hard to nail down your preferred workflow / setup ... but it's likely worth it if you're using it daily!
Are there any good visual or video demos of using this type of setup? I'm having trouble picturing what makes people really love this type of TUI-only workflow.
I typically have a terminal-heavy workflow so it's very rare that I'm browsing to files from within my desktop, but if I am using Dolphin to look for a file I have a "Open terminal here" shortcut and then I'll usually just run "nvim doc.md".
Why not give it a try? You'll likely find that there's an adjustment period and you can always switch back to your old editor if you don't like it. The beauty of it is that you can build it into whatever IDE you want instead of having useless features shoved into your IDE whether you use them or not.
This kind of setup is at its most powerful when you live on the command line though. For instance, you need to modify .py files across multiple projects that mention a certain variable, have a certain word in their name, and were modified within the last month.
That search is a bit easier in bash/zsh than it is in most IDEs and the strength of vim/neovim is the shell integration.
There's a hackish way to do it by watching for Neovim command line commands that start with "/Users/" (change it if you are on other OS).
Your coding agent can probably hack something up based on:
`//Hackish supports drag and drop files into Neovim by examining when command line starts with "/Users/".`
Just use a fuzzy file finder within the terminal or within vim itself.
The nice thing is that I rely only on the keyboard, no need to point with the mouse. It may not be faster, but typing is sequential and there’s no context switching. So muscle memory helps a lot. Just like you don’t think about each character when you write, I don’t really think about the shortcuts and commands I use.
Another thing I picked up from my time with emacs was making keybinds to interact with the "other" window. One macro I use often will delete the second line of the file in my current window, save, change to the other window, delete second line, save, change back to original window. When activated from keybind it all happens approximately instantly. I also have some binds to jump to the top of the other window's file (without leaving my cursor stuck over there) and so on, letting me keep my cursor in the main area most of the time.
Also the buffer’s local variable in vim comes from different sources. In emacs, a lot of stuff are tied to a major or minor mode. You only have to toggle them to switch between keybinds, syntax,…
My setup looks something like this:
ai is an independent tmux window where I can shuffle between project groups.for AI I found oh-my-pi from can1357 it's magical how good it is. It was a top rated post on HN awhile back.
i can tell you dont actually SSH often by tbe way. Also, tmux doesnt magically reduce resource requirements of your applications
You're right. I don't use SSH that often due to kubernetes, infact I only use ssh for connecting to my desktop to access my tmux sessions and it's great. I know where you're trying to go with this and it's simply not true.
Who said anything about tmux? We're talking about neovim which is extremely light weight and the LSP's don't sit around being active all the time. They have a set duration where they terminate when unused which is simply not possible in most IDE's (LSP based ones are OK, but have problems reconnecting).
This isn't right. It was certainly true in the nineties, but I haven't seen one in years on Windows and I spend many hours a day in it both for work and play.
and kernel panics are exceedingly rare on windows. i havent BSOD'd in eons
I haven't had a kernel panic once on reliable hardware. Linux is way more stable than windows device drivers and progressively less reliable graphics drivers.
"yes I mentioned tmux as"
lol. good day
I don't think comparison to other editors is a good basis for deciding what should be pulled in. The vi ecosystem was and remains weird to those outside, but in a way that is internally consistent to the usage patterns of its own user over decades.
Also, percentage of users using X feature is also a bad selection criteria for pulling a plugin provided feature, unless that number is 100% and there is little deviation in configuring it. There is very little friction in pulling in a plugin as a user.
So what are some good criteria for absorbing plugin functionality?
- extensions that provide an API for entire ecosystems (plenary, lazy.nvim)
- plugins that add missing features or concepts that are to useful, and timeless to ignore
- plugins that would benefit themselves or neovim by moving to native code
Honestly, the bar for absorbing plugins should be pretty high. There should be a real benefit that outweighs the cost of more maintenance, coupling, and ultimately cost.
The cost of installing plugins is pretty low, and they are great at keeping the core software simple.
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.
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.
Original HN post here if you’re interested. https://news.ycombinator.com/item?id=7279358
I've always wondered what this legend is doing now
For some, this stage of a project attracts tinkerers and builders, and lets the community shape how things are done in the future. It's not always practical, but it does have a certain appeal.
[1] https://github.com/jrop/morph.nvim
> "can't do things since there are no plugins yet"
Depending on what I am doing, I will probably go back to VSCode to get things done. Terminal editors are nice, but VSCode's extension ecosystem and usability is unmatched. I speak of that as someone who has spent hundreds of hours developing VSCode extensions. For me, "can't do things" is not (necessarily) a reason to set up Neovim plugins. It means I should figure out 1) if that's something I need to do regularly 2) If so, what's the best way to get it done.
(I am very well aware of what you can do with vim/Neovim plugins, just like zsh and tmux etc. Not spending time hand writing my config or setting up my plugins is an intentional choice. I like to start with a commonly used setup, discover pain points and bottlenecks, and then optimize or find some other solutions.)
Your arguments here are valid, for a particular kind of person who values a particular kind of workflow.
Some of us would rather use vi than vscode. If you take away the plugin ecosystem, the core value is still there.
The entire software development world would be much simpler if nobody needs new features, bugs and CVEs don't exist, or "just pin the version" works.
At this point I just want a decent Helix-Evil-Mode.
> 0.13 “The year of Batteries Included”
> 0.12 “The year of Nvim OOTB”
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”.
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.
https://neovim.io/roadmap/
Multi cursor is the feature that increased my productivity the most across the board.
(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.
That said, I do find myself using recursive macros quite often. They're an easy way to make a set of random little changes which would be hard to put into a solid regex. Especially when filtering and formatting logs to produce a list of error messages on a condensed format for review. It doesn't happen as often, but I also find them incredible when doing more complex substitution across a project.
2) Regex is great, and vim is a good place to exercise the “try a regex” reflex. And on the regular old bash command line, it is great for making stuff like locate more precise.
Since VS Code is already an inefficient way to move around a code base, I don't think we should take any lessons seriously outside of how useful the LSP protocol become for adoption.
P.S.: multi-cursor is not about moving around the code base and therefore not taking lessons about navigation has no impact in this matter.
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.
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_...
I will have to try it out once it lands in neovim just to see if I can wrap my muscle memory around it.
It's entirely possible that you don't need multiple cursors
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.
If those places can be created automatically then again it's just a macro you execute over many lines.
You search for OLD, replace it with NWE, then notice the typo, delete 2 chars and type EW. How can search and replace help you here without searching for NWE anew?
Yeah, do try it out to at least see the difference
How does multiple cursors work anyway? How do you place them? By search? Is it used for anything other than working on matching text?
And it's also used for new text entry, not just editing matching text, e.g., add an extra field to each of these 5 arrays
https://m.youtube.com/watch?v=jNa3axo40qM&t=23s
Much more powerful than "change all my selections to the next input" IMO.
So you either cycle through cursors (if your editor has a concept of "primary cursor") to see before/after or you do it blindly and accept a chance to be wrong
Otherwise, as a sibling comment said, incremental search/replace is your friend.
Oh neat!
What sold me was not even the editor itself at first, it was the workflow. I can leave sessions running, bounce between projects instantly, and my system still feels light. That matters a lot once you get used to having multiple things going at the same time.
Claude Code also helps a lot with the rough edges. When I run into some niche config issue or weird tooling problem, it is usually fixable in minutes instead of turning into a rabbit hole.
Most of the previous features are replicable with new code, except for incremental selection. treesitter-modules[1] serves as a good bridge between old and new APIs.
[1] https://github.com/MeanderingProgrammer/treesitter-modules.n...
Note that this might conflict with some text-object plugins, such as mini.ai, which define an/in by default.
https://github.com/neovim/neovim/issues/20451
https://neovim.io/roadmap/
https://github.com/neovim/neovim/issues/20451
Just kidding, that will never happen.
https://neovim.io/charter/
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.
My initial issue: https://github.com/neovim/neovim/issues/35258 The interactive issue: https://github.com/neovim/neovim/issues/1496
I really just want a, do the old thing setting. It was simpler and worked better.
[0] https://gist.github.com/Konfekt/8e484af2955a0c7bfe82114df683...
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
https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....
Verbose? The new plugin manager's interface is literature just vim.pack.add({url}), not sure what is verbose about that
You may argue that you don't need lazy loading, which is fine, but they're not 1-to-1 compatible.
[1]: https://github.com/neovim/neovim/issues/35562#issuecomment-3...
But as indicated by my comment in the specific case for lazy loading, the plugin manager is the wrong place to have it. Regarding its other features I am not sure most of them need to be part of the plugin manager either (at least from the "plugin spec" part) and are better suited as extensions to other parts of core neovim (e.g. options for plugins might need better `vim.{o,g}` support for nested objects, unsure). Maybe specifying nested dependencies might make sense to add to `vim.pack`.
All this to say: yea, now it is more verbose, but it doesn't have to be.
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
https://learnvimscriptthehardway.stevelosh.com/chapters/53.h...
Pressing C-z on neovim puts me back in the terminal so I can do whatever I need to do and when that is done I just type 'fg' in the terminal and it opens up my neovim again, exactly as it was.
Either opencode, claude, gemini, copilot, basically most that are relevant :D
Its a pretty light connection-layer, so it helps with sending context.
:term claude
In a split goes a long way for me!
https://github.com/coder/claudecode.nvim
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.
I’m still not clear on what Mason is doing in my config after the switch but oh well.
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.
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...
vim.lsp.config(<lsp server>, config)
just return the config as a table i.e
vim.lsp.config("emmet_ls", { filetypes = { "html", "css", "sass", "scss", "less", "svelte", "gotmpl", }, })
will become
return { filetypes = { "html", "css", "sass", "scss", "less", "svelte", "gotmpl", }, }
in lsp/emmet_ls.lua - file name is very important btw
Update: after updating everything the errors have disappeared, phew.
https://vimgolf.ai
I proxy to neovim instances for each level. Still working out some kinks but soon to complete it
[0] https://gist.github.com/Konfekt/8e484af2955a0c7bfe82114df683...
!make !ps aux Etc.
The new ! just isn't as useful, and it's harder to get back to see the outputs. The old ! Was just a drop in way quickly do something like ctrl-z command fg.
Until something comparable for Neovim comes out, I just don't see how I can switch back. I would happily pay for this. I'm sure there are a lot of people in the same boat as me.
The vast vast majority of my code is written by Claude Code, so I don’t write much. But when I do it’s like an exercise in warding off programming atrophy
I'm hitting the limit due to a system that uses lists of nested rules or decision trees.
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?
[1]: https://www.lazyvim.org/ [2]: https://youtu.be/N93cTbtLCIM
Course and book (free html, available pdf and dead tree). Covers everything I've needed concisely.
: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!
For doing something quick, VS Code's Vim mode is… fine. But not if you're something serious. I often quit it in disgust and go back to Neovim.
Why does it need to? Just open CC in another terminal window or tab. Or run it in a split inside vim, using `:term`.
Are there specific features you’re missing from vscode?
One major difference is neovim allowing to use Lua for configuration and plugins. I find Lua to be neater than vimscript.
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.
Although no LLM support in the editor, I personally just run Claude Code in a separate terminal, but if you want AI in the editor you'll have to look elsewhere.
I did try Neovim with Copilot a while back, and Google shows a few NeoVim Claude Code plugins, so it's probable that if you want an LLM in your text editor, NeoVim might work :)
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.
why "slow" just re-write it with ai. and to be clear im 0% joking and am prepared to be downvoted by people who haven't yet understood how feasible this kind of thing already is and how utterly trivial it will be in the near future
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.
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.
The Neovim developers have been extremely clear that part of the process of getting to 1.0 is finalising the API, and that there will be breaking changes en-route.
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.
https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....
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.
That being said, there is a way to lazy-load the plugins — Evgeni has a guide for that [1]. The "Load not during startup" variant is really simple with putting `vim.pack.add()` into `vim.schedule()`. The other myriad of options (keys, cmds, event) that lazy.nvim provides would require you to set up appropriate autocommands.
It gives me vibes of writing in Go. Everything is right there — builtin — but there's some verbosity to bear with.
[1]: https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....
This is actually super interesting, but then I realized it can't be true. :)