> For over 30 years, Vim has been "Charityware," supporting children in Kibaale, Uganda. Following the passing of Bram Moolenaar, the ICCF Holland foundation was dissolved […] and its remaining funds were transferred to ensure continued support for the Kibaale project. […] Vim remains Charityware. We encourage users to continue supporting the needy children in Uganda through this new transition.
I settled on vim for its technical merits but Bram using his goodwill to fund a charity like this for so long always made me feel good about my choice.
I used to work for a large enterprise, and tried to get vim ‘approved’ for internal use. I remember this charityware clause caused our legal department to get tied up in all sorts of arguments about how we could be opening ourselves to liability if we used it without donating. It was my first lesson in navigating large company processes.
In the end I just kept quiet about the fact that it ships in all the Linux package repos.
(Just to be clear, I fully support what Bram did here)
I agree and I know what you're saying, but I'm pretty curious: how are people using AI with vim? I've seen some scripts for ollama but what are most people doing?
AI makes advanced IDE features less relevant (or, more precisely, much easier to ignore or work without.)
I still have PyCharm, especially for working with data which I do a lot it helps quite a bit, but by default I'm back to a very vanilla Vim setup. Others have mentioned tmux which is great and I'd use anyway especially over ssh, but even just terminal tabs for instances of agents are fine frankly.
This. With so much of my work being done with Claude Code via terminal, I’ve used vim and tmux more than I have in the 20 years since I was first introduced.
I made a vim extension where you describe the edit/action you want in natural language, and my ollama model thats trained on books like Practical Vim returns the key sequence and you can press e to execute without leaving vim. So you get automation help but also learn the syntax.
I'm glad to see that Vim9 continues to make progress. The center of gravity may have shifted somewhat towards Neovim, but the Neovim ecosystem currently seems targeted towards people who want something more IDE-like.
One question is: will more plugin authors move to Vim9Script? It seems that Neovim users have generally moved towards Lua-based plugins, so there's less of a motivation to produce plugins that support both Neovim and Vim9.
> That said I'd have preferred something other than Lua if I had the choice.
Same. I know we as a community would never agree on what that language should be, but in my dreams it would have been ruby. Even javascript would have been better for me than Lua.
Lua, especially with LuaJIT, is nearly as fast as C. I certainly don't want to have to run a slow language like Ruby or especially a full blown JS runtime like V8 just to run Vim, the entire point is speed and keyboard ergonomics, otherwise just use VSCode.
Because I know javascript a lot more than I know Lua (and I suspect given js popularity, a lot of people are in the same boat). Yes Lua is easy to learn, but it's still different enough that there is friction. The differences also aren't just syntactically, it's also libraries/APIs, and more. I also don't have any need/use for Lua beyond neovim, so it's basically having to learn a language specifically for one tool. It's not ideal for me.
But the people who did the work wanted Lua, and I have no problem with that. That's their privilege as the people doing the work. I'm still free to fork it and make ruby or js or whatever (Elixir would be awesome!) first-class.
I agree but also wonder if editor plugins fall squarely in the range of things an LLM could vibe-code for me?
There is a large class of problems now for which I consider the chosen programming language to be irrelevant. I don't vibe code my driver code/systems programming stuff, but my helper scripts, gdb extensions, etc are mostly written or maintained by an LLM now.
i’ve written probably north of a million lines of production js, maybe around 100,000 lines of production ruby, and about 300 lines of production lua. lua is a fun language and i think a much better fit than JS for technical reasons (who has a js engine that is both fast and embeds well? nobody), but i am certainly more productive in those other languages where i have more experience.
lua array index starting at 1 gets me at least once whenever i sit down to write a library for my nvim or wezterm.
I am a lay user or vim. I use it daily for editing text files and a bit of code, but I always found the plugins and the scripting language rather daunting. There are different, conflicting, plugin management systems; and of course there's the scripting language that's vim-specific, and the few times I tried to delve into this stuff, I quickly found myself in over my head.
So - on the occasion of VIm 9.2 coming out - do people have a recommendation for a gentle path to "leveling up" one's VIm skills and engagement?
Why would they do that? When I started learning VIM more than 20 years ago, one of the main reason was that it (or vi) was already present and installed in every possible Linux system.
If the thread was deleted by a mod or flagged in the time between starting a comment and hitting "reply", you'd see a message that "you're not allowed to post a comment here" or similar language. Nothing to do with you, it's the state of the thread you're commenting on.
This is the perennial argument that IMHO is based on a fallacy. If the vim people suddenly stopped working on vim, it doesn't mean all their effort would go to neovim. People work on what they want to work on in open source. Also the two projects have very different goals/philosophies. The code bases have also gotten pretty different in architecture because neovim did a monstrous refactor. It's open source working as intended that we have both.
One little thought is, has there been much drama between the vim and neovim communities? (I guess community can be defined broadly enough that the answer to that question is always “yes,” but I haven’t seen much). They both seem completely happy to just do their own thing. I think the perennial argument just exits in the mind of some fans.
It is nice to see a pair of projects with so much potential for competition coexisting peacefully. Plenty of room on the internet I guess.
Technically, Neovim started because the author wanted to add multi-threading to Vim but the patch was rejected. So they did try to contribuir to Vim first.
Not that I agree with your parent comment or anything (I don’t), I use Helix so don’t really have a dog in this fight, I think it’s fine for them all to coexist.
But they're separate highly maintained projects, and there will always be tradeoffs. It's like saying that Ubuntu is better than Debian, or that Fedora is better than RockyLinux.
well the library ecosystem, developer tooling, and gradual typing support for lua is far ahead of what’s available for vimscript. in my experience lua is #2 behind javascript/typescript’s #1 when it comes to scripting language LSP stuff. both python and ruby suffer from a profusion of alternative type checkers and whatnot that cause pain and fragmentation when it comes to tooling.
it’s pretty great to have my vimconfig give red squiggle in editor if i’m doing it wrong before i save & reload.
but i’ve not followed vim9 script as its evolved perhaps there’s a good type checker for it at this point?
even before neovim, there were vim extensions written in lua so it feels gravity of lua code has been considerable for a long time.
to me vim9script feels like perl5/raku split - evolution too late to grow new users, a remnant for a niche that will fade to oblivion slowly over the next 10 years.
> For over 30 years, Vim has been "Charityware," supporting children in Kibaale, Uganda. Following the passing of Bram Moolenaar, the ICCF Holland foundation was dissolved […] and its remaining funds were transferred to ensure continued support for the Kibaale project. […] Vim remains Charityware. We encourage users to continue supporting the needy children in Uganda through this new transition.
I settled on vim for its technical merits but Bram using his goodwill to fund a charity like this for so long always made me feel good about my choice.
I used to work for a large enterprise, and tried to get vim ‘approved’ for internal use. I remember this charityware clause caused our legal department to get tied up in all sorts of arguments about how we could be opening ourselves to liability if we used it without donating. It was my first lesson in navigating large company processes.
In the end I just kept quiet about the fact that it ships in all the Linux package repos.
(Just to be clear, I fully support what Bram did here)
But where are the AI features?? Gonna get left behind!
Only joking of course, actually quite refreshing to see a new version announcement of something this major without any AI nonsense.
I agree and I know what you're saying, but I'm pretty curious: how are people using AI with vim? I've seen some scripts for ollama but what are most people doing?
AI makes advanced IDE features less relevant (or, more precisely, much easier to ignore or work without.)
I still have PyCharm, especially for working with data which I do a lot it helps quite a bit, but by default I'm back to a very vanilla Vim setup. Others have mentioned tmux which is great and I'd use anyway especially over ssh, but even just terminal tabs for instances of agents are fine frankly.
tmux + vim + Claude Code
This. With so much of my work being done with Claude Code via terminal, I’ve used vim and tmux more than I have in the 20 years since I was first introduced.
How many people don’t know tmux in the industry is really beyond me.
same, although I'm using zellij instead of tmux. Copilot works well in vim too.
The copilot plugin works well
That's good to know. I've never actually tried Copilot. I was going to try this week.
I made a vim extension where you describe the edit/action you want in natural language, and my ollama model thats trained on books like Practical Vim returns the key sequence and you can press e to execute without leaving vim. So you get automation help but also learn the syntax.
That's pretty nifty. Link please
:please exit vim now
I'm glad to see that Vim9 continues to make progress. The center of gravity may have shifted somewhat towards Neovim, but the Neovim ecosystem currently seems targeted towards people who want something more IDE-like.
One question is: will more plugin authors move to Vim9Script? It seems that Neovim users have generally moved towards Lua-based plugins, so there's less of a motivation to produce plugins that support both Neovim and Vim9.
I'm not the target for your question (I distribute 0 plugins).
But Lua support in Neovim is the primary reason I moved over from Emacs. Elisp and Vim are both so heart sink for me.
That said I'd have preferred something other than Lua if I had the choice.
I wish they supported Janet
Can you run Fennel in Neovim? It's a Lisp running on Lua. https://fennel-lang.org/
> That said I'd have preferred something other than Lua if I had the choice.
Same. I know we as a community would never agree on what that language should be, but in my dreams it would have been ruby. Even javascript would have been better for me than Lua.
Lua, especially with LuaJIT, is nearly as fast as C. I certainly don't want to have to run a slow language like Ruby or especially a full blown JS runtime like V8 just to run Vim, the entire point is speed and keyboard ergonomics, otherwise just use VSCode.
Quite a fair point! For intensive plugins and such, this would matter quite a bit.
Babashka! Super fast clojure/lisp.
there's always fennel for a lispy layer over lua
> Even javascript would have been better for me than Lua.
Why?
Because I know javascript a lot more than I know Lua (and I suspect given js popularity, a lot of people are in the same boat). Yes Lua is easy to learn, but it's still different enough that there is friction. The differences also aren't just syntactically, it's also libraries/APIs, and more. I also don't have any need/use for Lua beyond neovim, so it's basically having to learn a language specifically for one tool. It's not ideal for me.
But the people who did the work wanted Lua, and I have no problem with that. That's their privilege as the people doing the work. I'm still free to fork it and make ruby or js or whatever (Elixir would be awesome!) first-class.
I agree but also wonder if editor plugins fall squarely in the range of things an LLM could vibe-code for me?
There is a large class of problems now for which I consider the chosen programming language to be irrelevant. I don't vibe code my driver code/systems programming stuff, but my helper scripts, gdb extensions, etc are mostly written or maintained by an LLM now.
i’ve written probably north of a million lines of production js, maybe around 100,000 lines of production ruby, and about 300 lines of production lua. lua is a fun language and i think a much better fit than JS for technical reasons (who has a js engine that is both fast and embeds well? nobody), but i am certainly more productive in those other languages where i have more experience.
lua array index starting at 1 gets me at least once whenever i sit down to write a library for my nvim or wezterm.
> who has a js engine that is both fast and embeds well? nobody
Fabrice Bellard! https://github.com/bellard/mquickjs
(I agree with you, just wanted to note this super neat project)
quickjs/mquickjs are good at embedding but nowhere close to luajit in terms of speed. (i have some experience with quickjs https://github.com/justjake/quickjs-emscripten)
as an aside i’m curious how quickjs/mquickjs compares to mruby in speed and size. something to ponder
Doesn't Vim support extensions written in several languages? Or was that removed in Vim 9?
It still does, but those only work with a Vim built that has those interfaces compiled in.
Delighted to see vim continuing.
Strange that there's no v9.2 tag in https://github.com/vim/vim/tags.
Oopps, missed that. Now there is a v9.2.0 tag and a v9.2.0000 tag
The relevant release commit is, https://github.com/vim/vim/commit/e7e21018fc0b60c153c8e668f6... (at time of writing, two hours ago).
It seems they didn't publish the tag yet though.
I am a lay user or vim. I use it daily for editing text files and a bit of code, but I always found the plugins and the scripting language rather daunting. There are different, conflicting, plugin management systems; and of course there's the scripting language that's vim-specific, and the few times I tried to delve into this stuff, I quickly found myself in over my head.
So - on the occasion of VIm 9.2 coming out - do people have a recommendation for a gentle path to "leveling up" one's VIm skills and engagement?
Congratulations!
>Full support for the Wayland UI
I really hope they never deprecate X11 support :) I doubt they will, but if they do, it will leave the BSDs without a good alternative.
Unless I'm misunderstanding the problem, Wayland is available on FreeBSD.
https://docs.freebsd.org/en/books/handbook/wayland
Some people hate wayland.
But surely not every BSD user?
Not every BSD user, but the one you're responding to is most likely in that camp.
Those people can contribute to Xorg server further development.
The thing that kicked off this thread was hope that vim will continue to support X11. No need for continued X development really.
On the contrary, because you will want to have those drivers when the time comes to reinstall the system with more modern hardware.
Without X Server support at the OS level for the new hardware, doesn't really matter if vim supports it on its source code.
Why would they do that? When I started learning VIM more than 20 years ago, one of the main reason was that it (or vi) was already present and installed in every possible Linux system.
> Vim now adheres to the XDG Base Directory Specification,
cool
YES. Wayland support.
Ignore my comment, testing whether I'm blocked
Hey man, you’re not blocked. Read you loud and clear. Happy Valentine’s Day to you and yours.
In case you're wondering: I'm not blocked in this thread, but I was blocked in a thread about ICE. I told them to thaw out.
If the thread was deleted by a mod or flagged in the time between starting a comment and hitting "reply", you'd see a message that "you're not allowed to post a comment here" or similar language. Nothing to do with you, it's the state of the thread you're commenting on.
Take your tinfoil hat off
Should stop and help with neovim
This is the perennial argument that IMHO is based on a fallacy. If the vim people suddenly stopped working on vim, it doesn't mean all their effort would go to neovim. People work on what they want to work on in open source. Also the two projects have very different goals/philosophies. The code bases have also gotten pretty different in architecture because neovim did a monstrous refactor. It's open source working as intended that we have both.
I agree with you.
One little thought is, has there been much drama between the vim and neovim communities? (I guess community can be defined broadly enough that the answer to that question is always “yes,” but I haven’t seen much). They both seem completely happy to just do their own thing. I think the perennial argument just exits in the mind of some fans.
It is nice to see a pair of projects with so much potential for competition coexisting peacefully. Plenty of room on the internet I guess.
There was a decent amount of drama in the early days, but at this point it seems like it's gotten pretty friendly.
Could say the same thing about people working on neovim
Technically, Neovim started because the author wanted to add multi-threading to Vim but the patch was rejected. So they did try to contribuir to Vim first.
Not that I agree with your parent comment or anything (I don’t), I use Helix so don’t really have a dog in this fight, I think it’s fine for them all to coexist.
NeoVim has a fundamentally better architecture and healthier ecosystem.
But they're separate highly maintained projects, and there will always be tradeoffs. It's like saying that Ubuntu is better than Debian, or that Fedora is better than RockyLinux.
Honestly curious, what are the tradeoffs with vim9 / vimscript?
well the library ecosystem, developer tooling, and gradual typing support for lua is far ahead of what’s available for vimscript. in my experience lua is #2 behind javascript/typescript’s #1 when it comes to scripting language LSP stuff. both python and ruby suffer from a profusion of alternative type checkers and whatnot that cause pain and fragmentation when it comes to tooling.
it’s pretty great to have my vimconfig give red squiggle in editor if i’m doing it wrong before i save & reload.
but i’ve not followed vim9 script as its evolved perhaps there’s a good type checker for it at this point?
even before neovim, there were vim extensions written in lua so it feels gravity of lua code has been considerable for a long time.
to me vim9script feels like perl5/raku split - evolution too late to grow new users, a remnant for a niche that will fade to oblivion slowly over the next 10 years.