I’ve been more and more often thinking about migrating the vim-rescript plugin from viml to lua, since it’s a way more ergonomic scripting language than VIML. The nvim community also seems to be pretty optimistic on making more lua plugins in the future. Also I’d get access to some useful nvim apis that would help building a more vim-centric experience.
Downside is that this would make the plugin pretty nvim centric… not sure if there’s a lot of users that rely on the classic vim / vi editor.
So… as a vim user, what version are you usually using when developing ReScript?
nvim
vim
vi
0voters
This doesn’t mean that I will do any changes right away. I am just gauging interest in such change and try to get a better understanding on what vim version everyone is using.
I don’t think anyone really use vi, or if they do, it’s because it is the only thing of this family available on a serveur through ssh, so I think nobody expect to have a decend rescript vi plugin.
From what I can tell, neovim seems to be more widly used, even if you still have a part of the community around vim which doesn’t make the switch. I only know neovim users in real life though.
Given that lua seems really better than vimL in terms of development experiences, I would prefer to have a good/great plugin in lua, with probably more than 60% (random number) vim/nvim users happy, rather than an ok-ish in vimL and everyone can use it. But the choice is all yours. Also, the vimL version of the configuration can be the same for both, vim and nvim, so I guess the non-neovim users can make the switch when they need to dev in rescript, if the plugins is written in lua.
I use Neovim. I’ve also developed plugins in both VimL and Lua. My vote is with Lua.
It should go without saying that writing Lua is a better experience. It’s easier and faster to write correct code. It’s more performant. There’s a larger pool of potential contributors.
As @kk3 mentioned, migrating to Neovim is super easy. Not sure if this is still the case with some of the more recent Vim8 features, but when I switched from Vim to Neovim a few years ago, it was a drop-in replacement. I didn’t have to modify my existing (1000+ line) config at all, it just worked.
I moved from SpaceVim (on neovim) to OniVim2 back to VSCode with the vim plugin. I feel like neovim is the correct direction to move, as they have been doing work on their own language server integration.
I’d like to add that neovim’s lua API is not stable and backwards compatibility is not ensured. The maintainers say they will do their best but don’t want to commit as they still may want to improve some APIs.
I’ve recently hit this when upgrading neovim 0.5 to 0.6. There were some functions that were moved in the vim.lsp.diagnostics namespace for example.
When calling them an error shows up and points you to the deprecated help page where things are clear on how to migrate, so the deprecation path is not just pure ininteligible breakage, but still, things are breaking here and there and require active maintenance.
All this to say that maintenance and nvim compatibility between versions may be a pain in the butt for a while, depending on what new shiny things you want to add to the plugin.
Yeap, that happened, mostly because the neovim lua API is new (starting at 0.5 and we are currently at 0.6.1), and they choose to have a short release circle. However, these changes should only happen between “major” version (0.X), that you can easily check with vim.fn.has('nvim-0.6'), the change will affect function scoping most of the time.
Some users use the nightly build though, which can change API at any time. I will consider make a “stable/main” version that support at least the latest version (0.6 support for example) and a “last nightly” compatible branch if changed are needed, that let us anticipate and being ready for the next release, and nightly user will have a working plugin.
So, yes, TLDR: you potentially need some effort to update to the newest api, but it will probably don’t ask that much of effort like a refacto or something, and I bet the community will notifiy/guide/PR if something is broken.
As long as our extension is mostly self-contained, i don’t think this will be a big problem. I am mostly worried about the existing VimL code, which is just annoying to maintain.