Gradual upgrades to lua are also fairly easy in neovim, since every lua function is available through v:lua on the vimscript side, every vimscript function is available through vim.fn on the lua side and conversion of datastructures between the two is almost seamless.
FWIW I’ve been using vim9script on and off for the last 6 months. I’ve enjoyed it a lot more than I’ve enjoyed using lua. The type systems hits a nice sweet spot for the use case. It is very similar to typescript 1.0. For app development I can see why typescript has evolved such an extensive type system. For vim plugins it has been nice to work with a system that doesn’t tempt you to get too specific just for the sake of specificity.
I can believe that :). I’ve heard of people programming neovim plugins in Teal, which as far as I understand is supposed to be to lua what typescript is javascript, perhaps you’d like it?
As far as I’m concerned, I find writing neovim plugins much nicer than writing vim plugins due to the APIs making much more sense and being better designed in general.
NeoVim has better support for Lua in the sense that the language is guaranteed to be available, has a first-class API and can be directly used for configuration (init.lua, ftplugin/*.lua, etc.).
You can’t rely on these languages always being there though as Vim can be compiled without them. I believe this is the reason why non-vimscript plugins for Vim never really took off. If you still think these languages count, then you should probably also think that Neovim can have plugins written in any programming language. Its language-agnostic RPC mechanism has access to almost all of the APIs the embedded lua interpreter has access to. There’s a bunch of Neovim plugins written in python, typescript and Rust, and lots of Neovim GUIs written in a variety of languages.
Sure, there’s some headaches there in theory. However in theory you can also compile vim without support for vimscript and that concern hasn’t prevented it’s adoption. In practice the various distributions almost universally build in support for vimscript. Likewise they almost universally build in support for auxiliary languages too. I’ve personally relied on python plugins that worked with the windows, macos, and debian distributions.
I’m not particularly interested in convincing anyone about the capabilities of neovim, either positive or negative. My comment was meant simply to reject the suggestion that adding classes to vim9script was at odds with bolstering support for other languages.
In this release is a new feature for naming colors (see :h v:colornames). There’s two dimensions to this. It is a simple UX improvement because you can give a more easily remembered name to a color and then use that name in highlight commands. It is also an extra layer of indirection that could open up new ways to generate and collaborate on color schemes. If you’re interested check out my vim-colorwheel (prototype stage) plugin that shows one such possiblity.
It’s almost as if Vim was taking the Microsoft approach with its competitor, NeoVim, by going the proprietary route. Either the NeoVim community invests in supporting the new VimScript, or the gap between the fork and the original is going to widen to a point of rupture. Maybe that’s for the best? I switched to NeoVim a few years ago, and since then have been quite puzzled by Vim’s strategy.
Or maybe it’s the stated rationale. I won’t reiterate every point because you can read it for yourself. However my feeling is that if neovim had been more ambitious and found a way to host typescript instead of lua then maybe vim would have just adopted it too (I’m assuming v8 would meet the perf goals).
I’ll be interested to see if Neovim is able to cherry-pick this Vimscript work and get the best of both worlds: performant Vimscript for backwards compatibility and/or new users migrating from Vim, and performant Lua for greenfield config/plugin work.
That’s somewhat unfortunate, but I get it! Probably a large undertaking for a relatively small perceived benefit, especially given the trend towards “Lua all the things” in the nvim community.
All things equal, I think most people would (objectively) prefer to write Lua (applicable elsewhere) vs Vimscript (niche, doesn’t have modern language features currently, etc…), especially if you’re starting circa 2022 without any legacy baggage.
That said, I also understand Vim’s/Bram’s prioritization of backwards compatibility!
IME vim9script is not backward compatible with legacy vimscript. They can call functions defined in the other language but that has been true of vimscript and lua for years. I think the lack of lua scripts for years. I think the primary reason people have preferred vimscript over the various other supported languages is that FFI details are difficult to get a feel for when also trying to make something new. It’s easier to keep track of quirks in the code you have in your visual frame than it is to keep track of quirks that only exist within the FFI bridge.
These language improvements seem to suggest the scripting interface will also provide type safety when you call vim builtins. I have to imagine that’s either been missing from neovim, or it’s a lot of neovim-maintained validation definitions that could have mistakes. I’d definitely want to get this benefit from the first party.
They want to make their own class system modeled on Java? I think I like the NeoVim approach of using existing languages more.
I don’t mind them adding to the vimscript language. This path means existing scripts can be upgraded piecemeal without needing a total rewrite.
Gradual upgrades to lua are also fairly easy in neovim, since every lua function is available through
v:luaon the vimscript side, every vimscript function is available throughvim.fnon the lua side and conversion of datastructures between the two is almost seamless.FWIW I’ve been using vim9script on and off for the last 6 months. I’ve enjoyed it a lot more than I’ve enjoyed using lua. The type systems hits a nice sweet spot for the use case. It is very similar to typescript 1.0. For app development I can see why typescript has evolved such an extensive type system. For vim plugins it has been nice to work with a system that doesn’t tempt you to get too specific just for the sake of specificity.
I can believe that :). I’ve heard of people programming neovim plugins in Teal, which as far as I understand is supposed to be to lua what typescript is javascript, perhaps you’d like it?
As far as I’m concerned, I find writing neovim plugins much nicer than writing vim plugins due to the APIs making much more sense and being better designed in general.
Fun fact: you can use lua in vim too. Also python. Also ruby. Also tcl. vim9script is just another language you can opt into.
NeoVim has better support for Lua in the sense that the language is guaranteed to be available, has a first-class API and can be directly used for configuration (init.lua, ftplugin/*.lua, etc.).
You can’t rely on these languages always being there though as Vim can be compiled without them. I believe this is the reason why non-vimscript plugins for Vim never really took off. If you still think these languages count, then you should probably also think that Neovim can have plugins written in any programming language. Its language-agnostic RPC mechanism has access to almost all of the APIs the embedded lua interpreter has access to. There’s a bunch of Neovim plugins written in python, typescript and Rust, and lots of Neovim GUIs written in a variety of languages.
Sure, there’s some headaches there in theory. However in theory you can also compile vim without support for vimscript and that concern hasn’t prevented it’s adoption. In practice the various distributions almost universally build in support for vimscript. Likewise they almost universally build in support for auxiliary languages too. I’ve personally relied on python plugins that worked with the windows, macos, and debian distributions.
I’m not particularly interested in convincing anyone about the capabilities of neovim, either positive or negative. My comment was meant simply to reject the suggestion that adding classes to vim9script was at odds with bolstering support for other languages.
You’re right, I took your comment out of context, sorry about this and thanks for noticing :)
In this release is a new feature for naming colors (see
:h v:colornames). There’s two dimensions to this. It is a simple UX improvement because you can give a more easily remembered name to a color and then use that name inhighlightcommands. It is also an extra layer of indirection that could open up new ways to generate and collaborate on color schemes. If you’re interested check out my vim-colorwheel (prototype stage) plugin that shows one such possiblity.It’s almost as if Vim was taking the Microsoft approach with its competitor, NeoVim, by going the proprietary route. Either the NeoVim community invests in supporting the new VimScript, or the gap between the fork and the original is going to widen to a point of rupture. Maybe that’s for the best? I switched to NeoVim a few years ago, and since then have been quite puzzled by Vim’s strategy.
https://vimhelp.org/vim9.txt.html#vim9-rationale
Or maybe it’s the stated rationale. I won’t reiterate every point because you can read it for yourself. However my feeling is that if neovim had been more ambitious and found a way to host typescript instead of lua then maybe vim would have just adopted it too (I’m assuming v8 would meet the perf goals).
V8 is much bigger than LuaJIT and IIRC for a long time LuaJIT was faster than V8 (maybe it still is) and it worked much better wrt FFI than Node.
[Comment removed by author]
I’ll be interested to see if Neovim is able to cherry-pick this Vimscript work and get the best of both worlds: performant Vimscript for backwards compatibility and/or new users migrating from Vim, and performant Lua for greenfield config/plugin work.
I remember hearing in a presentation that neovim team does not want to spend time on Vimscript 9. Here is one issue mentioning that it is not a priority https://github.com/neovim/neovim/issues/13625, and a wiki https://github.com/neovim/neovim/wiki/Merging-patches-from-upstream-Vim#types-of-not-applicable-vim-patches stating that patches with Vimscript 9 are “Not Applicable”
That’s somewhat unfortunate, but I get it! Probably a large undertaking for a relatively small perceived benefit, especially given the trend towards “Lua all the things” in the nvim community.
All things equal, I think most people would (objectively) prefer to write Lua (applicable elsewhere) vs Vimscript (niche, doesn’t have modern language features currently, etc…), especially if you’re starting circa 2022 without any legacy baggage.
That said, I also understand Vim’s/Bram’s prioritization of backwards compatibility!
IME vim9script is not backward compatible with legacy vimscript. They can call functions defined in the other language but that has been true of vimscript and lua for years. I think the lack of lua scripts for years. I think the primary reason people have preferred vimscript over the various other supported languages is that FFI details are difficult to get a feel for when also trying to make something new. It’s easier to keep track of quirks in the code you have in your visual frame than it is to keep track of quirks that only exist within the FFI bridge.
Vimscript 9 support is explicitly a non goal of the project charter.
These language improvements seem to suggest the scripting interface will also provide type safety when you call vim builtins. I have to imagine that’s either been missing from neovim, or it’s a lot of neovim-maintained validation definitions that could have mistakes. I’d definitely want to get this benefit from the first party.
It may be possible to write compiler for vim9 in Lua and then use that.