The State of Vim
202 comments
·January 24, 2025omoikane
eviks
that'd be the wrong lesson to extend a period of using a bad governance model for longer
flohofwoe
You need someone to say 'no' to all the stupid ideas, and also to the occasional good idea to stay focused. Committees and communities are quite bad at that. IME the BDFL model has mostly worked best for open source software development, unless the BDFL is a complete ass of course.
(also software projects don't need to be democracies, e.g. people won't starve or sent to the gulag if things go sideways)
johnnyanmac
It's the best, when you find one. But the approach is also the riskiest. You may not even pick a BDFL to begin with (I'm sure many of us can name certain repos overly held back by a bad or muddy vision, or being overly conservative with feature/pull requests) . or that B fades away for any number of factors. Committees sacrifice that cohesive vision and agility for being able to have some checks to potential rouge actors.
tomrod
One of the most powerful ideas I've come across is Arrow's impossibility theorem, which basically states that you don't get a lot of nice group choice outcomes without a dictator in the mix. It's a math formulation, so its not commenting on the realities of a despot, but rather, someone's choices will always dominate if you want a certain set of properties in the decision making.
https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theore...
StefanBatory
Or HN too. I think most of us would agree that dang is a very good moderator.
pif
> software projects don't need to be democracies
Especially opens source ones, where anyone can spawn their own kingdom via a simple "git clone".
giancarlostoro
> unless the BDFL is a complete ass of course.
I think in the case of Linus, you REALLY have to be strict. I mean, its arguably one of if not the most used pieces of software deployed in enterprise and globally for all manner of use cases.
bee_rider
Yeah, “dictator” was probably the wrong word. The characteristic of an actual dictator (even a benevolent one) is that they can enforce their will through violence if needed (benevolent ones usually don’t, but they could).
As quote goes, “I thought we were an autonomous collective.” Humans have some sort of tribal or pack instinct; if we want to do a project, we’ll often naturally form up around the person who’s doing it, willingly and without compulsion. The leader is the leader because everyone agrees they are doing good enough.
Open source project is sort of an ideal form of this. Unlike physical projects, the ability to fork for free means that the leader doesn’t even have the implicit moat that a potential alternative leader needs to take the current work-in-progress away from them.
BDFL is just a joke title.
psychoslave
Unless your software deals with tracking people within an organization that will of course comply with the political parties that rule the regions where there software operate.
eviks
Saying "no" is the easiest job in the world, and committees are pretty good at it. That's why we have decades-old design failures everywhere, because saying "no" to an improvement is so much easier that doing the actual governing and resource allocation to see it through, especially with volunteers
And given the article describes big fails at basically every aspect of project management (from github account to money and website), not sure where you see the benefits of the supposed "focus"
porphyra
Many of the Vim nerds I know, including myself, have switched over to Neovim. Only when using a remote server with a default installation do I use regular old Vim.
112233
Neovim sounded like a good idea, so I switched, too. Then after an update, it broke mouse selection in terminal, by turning on some crazy option by default. I still have to search how to disable it each time. Ok, things like that happen. Then, after another update, it broke terminal update. Like, your screen scrolls up or down a line and the text does not get redrawn correctly. Is it a wezterm issue? Well, the original vim works flawlessly. So do less, top, and any other terminal programs. Except neovim.
No thanks. I dont care how many golden elephants are in the trunk if I cannot drive it.
maleldil
Vim is more stable simply because it changes less often. Neovim is constantly improving its APIs, and that can break stuff. If you don't want to deal with breaking changes, just don't update. You can still use most plugins.
wruza
Breaking changes and mistakes are orthogonal to changes to defaults and changes for no clear reason. This separates stable software from perpetual “nightly” one. With Vim you can update through a couple major versions before even realizing it. For me it usually happens after system crashes (classic reinstall windows twice a decade) and the vim config and my habits just work with a new vim download.
If neovim thought that something was broken, it was a very valid reason for a quick change. That’s how changes are made and I think most Vimers respect that. It was a proper community fork, almost a textbook example despite the initial buzz. Everyone got what they needed.
But if you refuse to update, it’s a clear signal for ideological mismatch. The usual issue with picking pace, as I see it through years, is that there’s often no clear finish line where you switch to walking again. The pace just stays like that forever and people start to grow tired of changes they were happy about.
Will that kill Neovim? I don’t think so. People who migrated to it (opposed to newcomers) were built for a change too and will probably “survive” all that. Is your method of dealing with it valid? In principle I agree, nothing wrong with that either.
112233
How do you propose I update my distro (fedora) and just don't update text editor? Are you in a habit of bringing a chroot with known good versions of your tools to every computer you ssh into? Like, I'd really want to have that. May it be I've missed some new thing that allows me to not update?
bee_rider
Neovim sort of reminds me of zsh, in the sense that I can never really figure out if there’s some underlying technical advantage or if it is just the case that some features people like have been turned on by default.
robenkleene
Not that I disagree that both Zsh and Neovim turn on some attractive features by default, but the `zle` line editor being more extensible than deadline and built-in support Treesitter/LSP support seem like pretty obvious technical advantages (for the folks the features those enable are attractive to).
linsomniac
Fellow wezterm user here, I occasionally have redraw issues with neovim, maybe once a month of heavy use. Whatever happened to ^L to redraw the screen, it seems to no longer work...
I've moved away from maintaining my own vimrc, and towards vim distributions, and they all seem to be neovim targeted. First it was LunarVim, and more recently after Lunar stopped being maintained to AstroVim. They have been quite good at batteries included vim, and I'll never go back to vim without LSP.
arusahni
Do you have your terminfo set up properly? I used to experience bad glitching when working with vertical splits, but it went away once I applied this. https://wezfurlong.org/wezterm/config/lua/config/term.html
wruza
Does this imply that Vim has no LSP support? Cause ALE is a Vim-spirited zeroconf-ish LSP bridge for those who don’t know.
lynndotpy
This was my experience. Couldn't get into Vim, and once so got used to Neovim it broke. :(
I really love the Helix editor, and haven't had these issues yet, but it's not intended as a 1-1 vim replacement.
kps
I've also seen terminal misbehaviour with neovim, not using wezterm, including incredibly slow redraws.
openmarkand
I have tried several times and I always switched back to vanilla vim. Neovim has various nice features but it requires a lot of time to migrate correctly IMHO. 20 years of habits are hard to leave, I think.
Sure the configuration file is retro compatible, but some of the plugins are better suited for neovim and vice versa. I use a dozen of them and if I switch permanently to neovim I'd like to start fresh using more "modern" alternatives that make use of the newer features.
myaccountonhn
I found the neovim community to operate a bit like the node ecosystem, you pull in a plugin for every problem that solves already solved problems their own way. The plugins are also very flashy with tons of animations, colors and emojis, which to me is just distracting. That said I think people should use what they like, and I am happy that there is a big community developing an alternative to VSCode. I just didn't feel it was for me.
I ended up moving to Kakoune. The community is small but the tool is so much better designed and integrates well with unix. That means that i can usually glue together whatever I need myself with 1-3 lines of config and don't need an entire plugin when I want something that isn't built-in.
openmarkand
> The plugins are also very flashy with tons of animations, colors and emojis, which to me is just distracting
I also have seen that the very first time I tried neovim. Some people may like it but I consider a terminal to be as simple as possible. Furthermore, I use often the CLI on non-GUI terminals where such non-ASCII characters can have various side effects (e.g. unicode bars, braille like progress bar and so on, those destroy your serial terminal line).
sevensor
The Unix integration is so very good. I have keybinds to fmt for line wrapping and date to insert timestamps, and I like being able to pipe a selection to dc to do some quick math. It’s so easy, I do it without even thinking about it.
sgarland
> The plugins are also very flashy with tons of animations, colors and emojis, which to me is just distracting.
I don't think I've seen plugins with animations (nor would I want to). Agreed that emoji in the terminal, modulo useful glyphs like language logos next to files in a directory tree [0], are distracting.
What I don't understand are people who add a million plugins, and then wonder why the startup performance is terrible. I have a fair amount, including some I honestly rarely or never need, and startup time is still 75 msec, which is fast enough for me not to be bothered.
emblaegh
When I migrated years ago (mostly to get access to some plugins), nvim gladly swallowed my old configuration with no changes. Then I could change to lua and other modern features at my own pace.
Flimm
By "swallowed", I thought you meant that Neovim silently deleted your files. I'm glad the context makes it clear that it didn't.
fp64
…I still haven’t switched to lua, all I need still works fine
gtsop
I went back and forth quite a lot until i decided to stick to vim. The reason being that I want to gain deep knowledge of my editor instead of depending on a gazillion plugins that occasionally break. Now, I understand this is something you can do with both vim and neovim, however the documentation of neovim is littered with both the vim docs and the new lua docs, and there is a vibe of "you already know all of vim, here is the lua equivalent", which made it very inaccessible to me. I decided I'll spend the time in the more simple editor of the two and maybe reevaluate this decision again in 3-4 years
nicoloren
I did the same. I mostly use Vim without plugin and a simple vimrc file. For the heavy stuff and big projects I use VSCode.
gtsop
I still use a bloated version of vim for my day job, since it involves huge react+ts apps. But i slowly build up a clean vimrc while writting my pet projects
jackthetab
:s/VSCode/Jetbrains/
wruza
Neovim turned itself into a pop-blink IDE which some people never wanted. It's good that it serves the needs of its fans, but it's also good that Vim stayed in its own tracks. Losing Vim as it is would be a great loss for many.
jitl
With no config file Neovim is just vim but with mouse mode enabled by default. With Lua and the new APIs it’s much easier to write powerful plugins that do crazy shit and use animation but none of that happens by default, you need to go out of your way to get that kind of action, same as with regular vim.
sodapopcan
It's not, though. A bunch has been stripped out (interactive :!, :view, etc) and time only time will tell how much further they will drift apart.
rand0m4r
I'm glad I'm not the only one who thinks the same thing.
I also think that "stability" and the "community" are two other things that made me switch back to vim.
rob137
What does 'pop-blink' mean in this context?
wruza
Something pops out and blinks on itself while you are typing. At least that's what I've seen in neovim "ads" videos back in the day.
CGamesPlay
I just set up a Neovim configuration from scratch and I have no idea what you are talking about. I did install a completion plugin literally called blink, but even that supports keybinding activation.
wruza
My transition was unsuccessful for a differrent reason, although I still think that while being open to change, it’s ideologically correct to stay with ideas you are aligned with.
When I tried it, nvim-qt was hard to associate with file extensions on windows (required something like “-- “filename”” in different shapes and hours of regedit debugging, can’t remember now), then nvim itself had issues with refreshing on manual window resize and with autoresizing the window on setting ‘lines’. And a few more os integration related issues. It was basically unusable gui-wise so I bailed out due to no good reason to stay.
I was probably talking about that astro-thing that works like a christmas tree and was the main selling point at the time.
lawn
> Neovim turned itself into a pop-blink IDE
What does that even mean? Just sounds like a lazy and false argument.
wruza
It was a selling point back then and the reason for a fork. Bram didn’t want to add async tech into Vim, cause async enabled various parallel-to-you visual activities. Neovim forked and did async+lua on its own terms. Vim later added async functionality, and I think it was the best outcome. Vimers still got shy LSPs and Neovimers got whatever they dreamed about in their separate emvironment. Good fork.
Things may have settled since then, maybe that’s why you think that this phrase looks odd.
mmooss
From the Stack Overflow survey:
https://news.ycombinator.com/item?id=42811182
Vim 21.6%
Neovim 12.5%
joeblubaugh
I’m willing to believe that “vim” combines some neovim users, but I’m not surprised that the original is still more popular. Anecdotally vim seems to ship new features faster than it did 3 years ago.
wirrbel
Braam really took Neovim personally and got better at getting stuff into vim that he wouldn't merge before once neovim was arround as a competitor. I really lost track of vim in the last years because neovim is just a solid platform with an active community.
But honestly at work, I think I am the only one using either a vim or emacs (I kind of use neovim and emacs but primarily neovim). In my childhood there was a TV series called "The last of his class" and it really showed old people (retirement age) doing jobs that will be gone once their retire. While some jobs truly vanished, others just transformed so drastically that they cannot be likened anymore to the job those folks did. Anyway, I feel we are watching changes in developer tooling that will be seen as the end of an era.
* https://de.wikipedia.org/wiki/Der_Letzte_seines_Standes%3F
bitbasher
I would prefer to use vim, but most plugins are limited to neovim these days. I also feel the overall speed of neovim is better and less janky when interacting with buffers and navigating files.
The treesitter highlighting in neovim is also better/supports more files out of the box than vim. In vim I was far too used to syntax highlighting being broke halfway through a file for one reason or another (lines too long, syntax new or broken, etc).
I dislike setting up neovim, but I also dislike vim's heavy use of language specific plugins. In a perfect world I'd have lsp+treesitter in vim out of the box and no need to install any plugins.
bawolff
People who describe themselves as "vim nerds" might not be representitive of the average vim user.
mmooss
Maybe, but it's hard to be a vim user without being somewhat of a vim nerd. At least you have to understand a new concept of interface, several modes, and lots of keyboard shortcuts - that would make you a nerd in any other application.
bawolff
Maybe, but i use vim everyday. I have no intention of switching to neovim simply because i don't know what the difference even is. There are levels to vim usage, and you can still be very productive while only knowing the basic keyboard shortcuts.
pjmlp
That is the only reason why while being on Emacs side, on the whole Emacs vs vi, I ended up learning enough vi to be productive on customers' UNIX systems.
ykonstant
> How can we make Vim9 script, the new Vim scripting language, more widely used?
One way is to inform users and prospective plugin writers that
1) Vim9 script is vastly superior to the old Vimscript, to the point where it is not unpleasant to use, and
2) it is much more conductive to writing text editor code than the general purpose Lua.
Of course this still does not mean that people will want to learn yet another scripting language to write Vim plugins in particular when they already know Lua, but it is very important to be adequately informed about the two above points.
otikik
> it is much more conductive to writing text editor code than the general purpose Lua.
Lua is very much not a general-purpose Language. It can be used like one, but it's a specialized language thought to live inside a "host" application, which it then controls. Which does seem to fit the usecase here.
Would you be able to substantiate your claim that it is more conductive to text editor code?
> it is not unpleasant to use
I'm afraid that is a very low bar. Lua is not unpleasant to use either.
ykonstant
No, I don't feel like substantiating my claims to someone who assumes a default hostile response to me and makes nonsensical readings of what I say.
For instance, when I compare Lua to vim9 script and say the former is general purpose, I am obviously in the context of comparing the one scripting language to the latter. And you know that. And yet, even though you understand the context perfectly, you still choose to write "Lua is very much not a general-purpose Language..." and proceed to patronize me on semantics.
So, will I be able to substantiate? Yes. Will I bother to do so to you? No.
otikik
I don't know how my comment as hostile. But sure, don't substantiate.
sodapopcan
Speaking purely technically here, vim9/L has an actual standard library tailored specifically to Vim. Lua has no standard library and you just end up delegating to vimscript anyway. But ya, if you want to use Lua for whatever reason then it's a pretty hard sell. But that's sorta what OP is getting at... how to make it more attractive.
sodapopcan
> Of course this still does not mean that people will want to learn yet another scripting language
I understand this sentiment and that there are certainly psychological blockers in having to learn too many languages, but vim9 is very simple to learn. It is much closer to a "familiar" language than Lua. Plus, you are going to have to be familiar with Vim's standard library anyway. I believe they are adding more and more helper functions but Lua plugins are full of `vim.cmd` and `vim.fn`. I don't dislike Lua as a language at all, but I much prefer "scripting Vim" in some sort of "VimScript" :) But to each their own.
ykonstant
I agree completely.
arp242
> it is much more conductive to writing text editor code than the general purpose Lua.
Personally I think that was already the case with "classic" VimScript, although I also appreciate it's a bit idiosyncratic and that many people don't have the time or interest to learn it.
I suppose that's also the problem with VimScript9. I agree is a real and meaningful improvement over VimScript, but I suppose that for many it's just "not important enough" to learn, even though it's not an especially difficult language to learn. I don't think that's unreasonable – there's tons of not especially difficult things I never bothered to learn in depth either, I just happened to choose Vim stuff at some point.
surajrmal
Honestly supporting a language is a lot of work. Documentation, language servers, ramping time for users to learn it, etc. I find it hard to believe vimscript9 is worth it over lua. I've seen the ecosystem for neovim seem to thrive, and in part because it looks like lua is a lower barrier language, especially if you've used it outside of vim.
dsign
The aggregate value of each soul that goes away is staggering. Bram is a good example; his work in VIM and his help to children in need will be sorely missed. I wish we were doing more to break that cycle.
dmortin
I wonder how long vim and emacs can stay vibrant. I've used emacs in the last 20 years, so I stick with it, but new generations who are trained on vscode and such are less likely to use such "old fashioned" tools.
Surely, there will still be emacs and vim users 50 years from now, but the user numbers and the community power will diminish as the graybeards gradually leave this plane.
Ferret7446
You can't really compare vim and emacs beyond a superficial level.
Emacs is fundamentally an interactive shell, like Bash. It has a text editor, also like Bash. It is of course generally more powerful and featureful than Bash.
Hence, people sometimes live in Emacs, because it's a shell like Bash or Gnome or KDE.
I use Emacs and VSCode. VSCode for some code repos, and Emacs for general computer usage.
Meanwhile, Vim is a text editor. It is neither a shell nor an IDE, although it can be adapted somewhat into an IDE.
I also use vi (alongside Emacs and VSCode). vi is for editing some text if I am not in Emacs for some reason or if I temporarily borked my Emacs config.
(I also use ed, for when I'm in a dumb terminal or I don't want to lose screen context.)
Vim or Emacs "dying" is not really an issue, although Vim or Emacs losing enough mindshare to keep them up to date as competitive IDE options, maybe that might happen.
qazxcvbnm
Just for the other side of the picture, I live in vim and use it as my terminal multiplexer. Vim’s my shell. I have thousands of buffers in vim and practically never leave it. I’ve used terminal multiplexers for years before I switched to vim in that capacity and never looked back. The integration it’s allowed between all my buffers and commands and shells is difficult to match in my opinion.
exogenousdata
As a 3rd anecdote, I used vim for 10 years as my primary editor and “shell”. Then 10 years ago I learned tmux and fell in love with its window multiplexing. Now I use vim strictly as an editor/splitter. But I use tmux to split my code from my repl window. And maintain multiple windows where I’m working on different projects.
rand0m4r
I'm going to try this. I use tmux but the idea of being able to use vim for everything seems nice. If you have tips/suggestions, I'm interested.
abraxas
Lots of editors and IDEs came and went while Emacs/Vim persisted. Through my three decade career I recall the ascents and downfalls of tools like BRIEF, CodeWright, NEdit, JEdit, TextPad, Notepad++, Visual Studio, JBuilder, Eclipse, Sublime and a few others so the cemetary (or hospice in some of those cases) is large.
the__alchemist
Sublime, nor Visual Studio are in the cemetery.
abraxas
Visual Studio is very much dying. Visual Studio Code is its successor that's very much alive. Those are two different products
ookdatnog
I'm sticking with emacs for now because it is the only editor I have encountered that actually works well in conjunction with a tiling window manager; by which I mean: it works well as a single process accessed through multiple windows (here I mean "windows" as in OS windows -- internally Emacs calls this "frames") although it has features for managing panes internally, it doesn't insist that you use them and each windows is very lightweight (no thick sidebars, embedded terminal, etc that are hard or impossible to remove). Vim offers the second feature but not the first (each window is a separate process), most other editors I've encountered do not offer the second feature.
sevensor
Kakoune does this too, and it’s amazing with a tiling window manager. On a big monitor, I can get 4-5 terminal emulators across, and in any of them, at any time, I can attach a kakoune client, copy and paste between buffers in different windows, edit the same file in two places at the same time, close all the clients and reattach later, and so on. Emacs is the only other editor that does this, as far as I know.
ookdatnog
Thanks, I might give that a try :)
rob74
To put it into perspective: vi was already 15 years old when Bram decided to write vim for the Amiga, which had a GUI - so vim already looked out of place on the Amiga too! - but it was still successful, of course (I think) mostly because of being ported to Linux pretty much at the same time as Linux got started.
joelthelion
To me, vscode is unbearably slow. I think that alone is enough to keep vim alive.
Also, I don't really miss anything from more advanced ides when in vim. There are great packages for almost anything.
atorodius
I use VIM bindings in VS Code. Always assumed many do but might be wrong
xarope
Ditto.
I went from vim to neovim, but the LSPs for python/go(lang) for large files (not that large, maybe 10k loc) seem to really bog it down (back then, no idea if it's better now), whereas with VS Code it was still performant enough. So I ended up using VS Code with Vim bindings.
And yes, with ad hoc work, I still end up using system vim when just doing simple edits (e.g. adding a line to README.md or somesuch)
dailykoder
At work I often switched to VSCode because I couldn't get pyright to work with our django project. The errors everywhere were just annoying to look at. So I looked around and found "ruff" and "jedi_language_server". This combination seems to do the trick. I don't have to configure anything. I source my venv and it "just works". I assume our python codebase is something around the 10k LOC, too. I am not mainly responsible for the python part, so I don't spent excessive amount of time in there, but for the time I do, it works nicely
matwood
Similar. I use IntelliJ, Neovim, and some Zed all with vim keybindings. Modal editing just fits my mind. As an aside it’s also one of the reasons I dislike Notion. I feel like I’m always inadvertently changing the content.
flohofwoe
Me too (there doesn't seem to be plugin that's completely free of issues unfortunately). Vi/Vim is basically the universal text input model which allows me to transcend text editors and platforms. Also I quite often find myself starting a vim instance inside the VSCode terminal for quick text edits.
orlp
I use the "VSCode Neovim" extension which lets me use a real Neovim instance inside VS Code, including my personalized vimrc and a lot of plugins. Not all plugins work but if they're just textual good chance they do.
wyclif
Do the Vim bindings work in VSCodium as well?
hnfong
This google trends graph is very illustrative: https://trends.google.com/trends/explore?date=all&q=emacs,vi...
emacs is surely on a decline, but it’s not obvious that Vim is on the same trend.
This matches “theory” and anecdotal evidence: the people who chose emacs probably didn’t like modal editing, and when “better” IDEs came along they just switched. But there’s nothing like Vim (except editors specifically inspired by Vim), and those haven’t gotten any traction if only because every one of us Vim users have hjkl muscle memory burned into our brains.
jiscariot
Google translate says vim = 'I came' in portuguese, so I guess that explains Brazil.
arccy
google trends can disambiguate the context
https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...
both decline, but emacs is steeper
Cthulhu_
I've never been able to use vim productively, at best I use it to write commits, do interactive rebases and some remote server configuration (cheap VPS for a website); I never really "grew up" with it and stuck with Notepad++ and Eclipse when I started out in software development nearly 20 years ago.
I will concede that VS Code is the default for many, but I just can't get productive in it anymore. I mainly use intellij, which has its own issues. But I can't say I've ever mastered any editor, the closest was sublime text, and that mastery mainly came from being able to use cmd+p and global search effectively.
skydhash
You probably have a good reason for not doing it, but mastering your editor is a great power up. Especially when the task can be ruled based and repetitive. Like a loop of find-select-transform action.
cassepipe
I had a easy to maintain, easy to understand vim + ALE + Gutentags + ... setup for C/C++ development and it worked very well but when I got into webdev I just gave up and jump to a neovim distribution as I was not able to catch up. So in the end neovim got me not because it is technically superior but because the community created distributions, which I am very grateful for (R.I.P Lunarvim)
EDIT: Ok, maybe the reason distributions were created is because the integration of some lsp/treesitter stuff enabled it/made it easier ? So if not technically superior, at least more capable
giancarlostoro
I assume slowly over time Neovim will just win over vim because of this. I do want to say its much more capable than the original vim, I don't know that vim has a headless mode or that it intends on it, but Neovim has that, plus it can essentially let you write plugins in any language with its plugin RPC protocol. So if you want a plugin that targets your language you can leverage existing libraries that directly support your language instead of writing it all from scratch in Vimscript.
t_mahmood
Vim does have headless mode, iirc. I used it with eclipse or netbeans, can't exactly remember.
I have Neovim, it still haven't replaced vim yet. But I see the reasoning, IF I want to use a editor to do heavy development, Neovim seems to have more detailed syntax highlighting, and yes LSP integration good.
I use intelliJ with ideaVim for my work, and I don't think these editors can fill the capability that JetBrains offers. Even though vim has a special place in my heart
giancarlostoro
> I use intelliJ with ideaVim for my work, and I don't think these editors can fill the capability that JetBrains offers. Even though vim has a special place in my heart
I keep wanting them to make a Neovim headless plugin for their IDEs.
pdimitar
I loved LunarVim as well but after switching to AstroNvim I like it more. And it's easy to customize even for a very burned out dev like myself.
cassepipe
I also jumped ship to AstroNvim but I still prefer Lunarvim, I liked having all the config in just one file and some of its defaults. But I agree, Astro is the best distro currently maintained distro in my opinion.
mehalter
You can definitely put all of your configuration into a single file for AstroNvim if you want.
In the docs it shows the minimal configuration to get AstroNvim running which is <10 lines in your ~/.config/init.lua file and then anything else you can just drop in that same file if you want. (https://github.com/AstroNvim/AstroNvim?tab=readme-ov-file#mi...)
Here is a user on GitHub that has a single file AstroNvim configuration: https://github.com/20k-ultra/dotfiles/blob/master/nvim/init....
pdimitar
One file worked fine until it didn't. At one point it was 500+ lines and became unwieldy to manage.
Though I might one day switch to Zed or Helix -- I want an editor that has more bells and whistles built-in and that I could just switch them off if I don't want them. Which should be a much smaller configuration footprint compared to what we have today with Neovim.
xenodium
Tangentially related and as an Emacs user, I still see the editor as a platform that bends to my needs https://xenodium.com/a-platform-that-moulds-to-your-needs
HellsMaddy
Previous discussion: https://news.ycombinator.com/item?id=42665222
Maken
>he started adding more potentially controversial changes, such as support for the XDG base directory specification
It feels like every single user-facing open source project needs to have its own XDG drama at some point.
BiteCode_dev
I don't understand how it's a drama. It's an old spec, it's easy to follow, it's standard, and you can still keep compact with the old .dir at user root if you want.
What's the big deal ?
eadmund
Some people really don’t like change. I understand that, but I think that the XDG directory spec is really worth having. It’s wonderful to unclutter $HOME.
But I do get that for those of us who’ve been using Unix for decades it can be a bit weird when stuff which used to be under $HOME/.$WHATEVER ends up under $HOME/.config/$WHATEVER.
weinzierl
"DNS was also troublesome—the vim.org domain was managed by Stefan Zehl"
vim.org was created (probably around 1998) and has been owned by Sven Guckes for most of its existence. In the beginning Sven also managed the content but I think at some point Bram took over. Unfortunately Sven passed away not long before Bram.
tannhaeuser
Worth noting there are still elvis and the one true vi available, in case vim gets foobar'd, though I haven't checked their respective states now and last used either over ten years ago. Like with shells, I've always wondered why people are so quick to jump onto particular implementations when the value is in the wide availability of editors implementing vi key bindings, and the comfort of building up muscle memory this brings. Obviously, I couldn't care less about "plugins".
kps
And nvi, the 4.4BSD unencumbered reimplementation.
LSP as a replacement for original vi's cscope integration is the main reason I eventually switched from nvi to vim.
alp1n3_eth
I'm glad I was introduced to NeoVim, because it led me to using Vim bindings in Zed.
As a new user to NeoVim, I was okay with investing some time, but man it feels like each update to NeoVim itself, or even the popular plugins, breaks something that I then need to go hunt down and fix. Every answer online isn't any better, pointing to 5 different doc pages. I like my IDEs to "just work" and continue to do so after I have them configured.
VIM seemed to have fared well under the new leadership, despite not being able to control the timing of this power transfer. Maybe other BDFL projects would be inspired by VIM's experience and setup successors early.
https://en.wikipedia.org/wiki/Benevolent_dictator_for_life