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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
> 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.
> 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.
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.
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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
Speaking for myself, I only used Neovim because of its modularity and the keybindings. Imho, everyone should give the basic Vim keybindings a chance at least once and see if they like it.
At this point, however, I do not really use Neovim anymore. I switched to Zed, the Vim emulation is pretty good and customizable and most functionality I want is already there along with incoming support for Jupyter Notebooks. VSCode also has these features.
It is fun to use Vim/Neovim but unless I need to use it, I doubt I will return to it.
Some time in the 80s (or maybe even 90s?) Bill Joy said he just uses ed, even though he's the original author of vi. That worked for him. I believe Linus still uses that 1980s Emacs-y clone that he kind of maintains for himself. jwz uses some flavour of Lucid Emacs/XEmacs from who-knows-when instead of "standard" GNU Emacs.
In the end, it doesn't really matter what other people are using. If Vim (or Emacs) works for you, then you can basically keep using it until the end of time since code are just text files, and these things don't really change all that much (outside of encodings, which is the biggest problem with older editors – but I don't see UTF-8 replaced any time soon, if ever).
I don't really know what the kids these days are up to, but I don't think it really matters. I guess there's still few Bill Joys around using ed, but the existence of vi, Vim, VSCode, or anything else doesn't really take away anything for them.
With nvim, there has been quite the resurgence of Vim. Good software tends to be resilient. I believe both emacs and vim will see many, many more years.
One of the kids in my computer club found himself to be an avid Helix user. I guess once the dust settles around nvim's approach to LSP and stuff, give or take 5 years, it will build itself quite a following, including young people. I think the hackability is attractive.
I think Neovim helps with this, though last time I was using it (via... bootstrap? One of the prebuilt addon packs) at some point a Mason update broke my LSPs for multiple languages and i went back to VS Code on my Linux laptop because I didn't want to fight with it.
I ran screaming from VS when I noticed how much resources it used and what software it copies on remote servers in case you want to work remote. Did this improve at all in the last year+?
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
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.
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
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.
Readit News
https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
(also software projects don't need to be democracies, e.g. people won't starve or sent to the gulag if things go sideways)
No thanks. I dont care how many golden elephants are in the trunk if I cannot drive it.
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.
I really love the Helix editor, and haven't had these issues yet, but it's not intended as a 1-1 vim replacement.
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.
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.
I also think that "stability" and the "community" are two other things that made me switch back to vim.
What does that even mean? Just sounds like a lazy and false argument.
https://news.ycombinator.com/item?id=42811182
I wonder what it looked like in prior years.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.
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.
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.
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.
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.
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.
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.
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.
Also, I don't really miss anything from more advanced ides when in vim. There are great packages for almost anything.
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)
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.
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.
At this point, however, I do not really use Neovim anymore. I switched to Zed, the Vim emulation is pretty good and customizable and most functionality I want is already there along with incoming support for Jupyter Notebooks. VSCode also has these features.
It is fun to use Vim/Neovim but unless I need to use it, I doubt I will return to it.
In the end, it doesn't really matter what other people are using. If Vim (or Emacs) works for you, then you can basically keep using it until the end of time since code are just text files, and these things don't really change all that much (outside of encodings, which is the biggest problem with older editors – but I don't see UTF-8 replaced any time soon, if ever).
I don't really know what the kids these days are up to, but I don't think it really matters. I guess there's still few Bill Joys around using ed, but the existence of vi, Vim, VSCode, or anything else doesn't really take away anything for them.
emacs is 4% vs VSCode 73%, so it's not popular, though vim still is
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
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