> You should ask, and answer, the question in reverse. What does neovim offer me, as a regular vim user?

Well, one of the goals of neovim was to make it easier for new people to contribute.

So, there's an obvious feature you might be overlooking: the project surviving past its creators passing.

Beyond that, async, lua, lsp and treesitter support are other things neovim brings to the table. I don't use vim much anymore, but I know that neovim incorporated them first. If vim did follow on some of those innovations, consider how long it might take for new vim maintainers to get to a point where Bram needed to be to keep up, without his guidance.

I wonder if there is a need for both vim and neovim in the future. Neovim was born out of wanting to do similar things to what the vim maintainers are considering.

I know you listed Lua already, but it's important to stress that. Bram _did not_ want Lua as the main scripting language, and created Vim9 Script as a "better VimScript" instead. That's a stark difference in the direction for the project, and it signals to me that Vim is not meant to reintegrate with Neovim. It's no longer a question of Vim catching up with Neovim.

However, this was Bram's vision. We don't know how the new leadership will affect that.

> Vim9 Script as a "better VimScript" instead. That's a stark difference in the direction for the project

Great point. I wasn't following vim much, so didn't know the context around the language changes.

That does seem like a core philosophical difference. I'm interested to see what the future holds.

it's not quite just a "better vimscript" language it's an incompatible language, if it was just improvement on top of the existing vimscript it would have been fine i think but what people are complaining about is if you are going to break compatibility why not choose an existing language like lua

Yes, you're right. That's what I meant, but I should've highlighted the incompatibility aspect.

Neovim's language server integration is a killer feature that got me to switch.

Absolutely! I started using LunarVim packages+configs on top of neovim), looks like a couple of years ago according to my work notes, and the LSP has been a huge improvement in my editing.

Can you explain the benefit? I'm not familiar with the feature.

Basically neovim can act as a client to a variety of different language servers (https://github.com/neovim/nvim-lspconfig/blob/master/doc/ser...) which give neovim IDE capabilities. This can be done in original Vim also but requires external plugins which can be a pain to compile and install. Neovim has it built in.

Maybe not important to some but the ability to use Lua over VimScript is a big win in my opinion. In fact, I use a mix of thr two where necessary.

How much of the rest of the vim ecosystem is Lua-based, though? As far as I know it's still mostly vimscript.

Vimscript's dominance in vim is one of the things that got me to switch to emacs when I got interested in Lisp and Scheme more than a decade ago.

Sure, even then I could write scripts for vim using Vim's scheme compatibility mode, but I'd probably be one of the only ones doing so. Pretty much everyone else was using vimscript.

In Emacs the whole ecosystem is in eLisp, so I'd feel right at home there, could naturally integrate other eLisp codebases/projects, could easily get help on anything related to working with eLisp in emacs.

If I'd written scheme scripts in vim my work would always be a second-class citizen in the vim ecosystem.

How's the vim ecosystem now? Is vimscript still dominant?

I think the ecosystem is more or less splitting. As a user, not dev, it looks like neovim "distributions" are mostly lua and would be feature complete (with some substituted plugins) even if 100% lua was enforced.

> How's the vim ecosystem now? Is vimscript still dominant?

You can have a full neovim experience with all sorts of modern extensions without using a single line of vimscript. Some people even replace their init (neovim's vimrc) with lua, but I am of the opinion that it is a step too far, as lua isn't particularly adapted to writing configuration files and the result is too verbose to my taste.

I have mainly lua config but just put in some vim files where I put bits and functions that were already written in vimscript.

Ah you see, you just wrap that lua in a lisp in some terse macros and there you go, instead of writing `:set formatoptions+=j` (yuck, vimscript!) or `vim.opt.formatoptions:append"j"` (vom, lua!) you can write the clearly superior `(opt formatoptions +j)` (heck yes, ivory tower).

My config is a horrible frankenstein of both.

I use lua when examples are in lua or when I need some "logic" (such as assigning defaults to a var and then passing that around/overriding). And that's embedded in vimscript.

I don't really like either. VimScript has always been a horror to me, eventhough I've been using vim for some 20 years now, almost exclusively. Lua is "that thing that I should really sit down and learn. But not now, I've got stuff to finish".

What does lua -for an end user- offer that something like yaml+python cannot offer? I really won't mind setting all sorts of flags, defaults and vars from some init.yaml, and then have some init.py to handle the few places where I do need actual logic. Why was lua picked, why did vim build its own language and not move to an existing one for its config? Am I just weird for never sitting down and learning lua? Or vimscript? Or both?

independently of vim configuration, lua is a cute general-purpose language worth learning in itself. It is much simpler than python, and the documentation is outstanding.

Lua is faster than Python and also easier to embed in vim [1] which are both big advantages for the end user. It means fast plugins and no hassle with having the correct python version.

Why Bram build is own language and then doubled down on it with vimscript9 I don't really understand.

[1] https://neovim.discourse.group/t/why-was-lua-chosen-for-neov...

> Why Bram built his own language [...] I don't really understand.

What language would have you chosen in 1991 instead of creating vimscript? The vimscript language is a very natural extension[0] of Bill Joy's "ex" language, that was used in vi since 1976. The history of vimscript is not weird, it's just a fairly natural continuation of existing practices. Vimscript9 is a least-friction update for modern times.

[0] https://en.wikipedia.org/wiki/Vim_(text_editor)#Vim_script

I should have written I don't really know anything about.

According to your link scripting was only available from '98, at which point Lua and Python were already around, but then I don't know how viable that would have been. Funny you say that about ex, because I find running ex commands from vimscript the most clunky thing about it.

In my opinion the least friction for the ecosystem would have been to follow neovim and adapt Lua.

Neovim's adoption has been incredible. Virtually every major vimscript plugin has either been ported or overtaken by a Lua-native alternative in the Neovim ecosystem.

I've also seen neovim plugins written in fennel [0], so if you want something lispy, that's possible now.

[0]: a Lisp that compiles to Lua, https://github.com/bakpakin/Fennel

> the ability to use Lua over VimScript

The Neovim people went a bit further with the integration, but you've been able to use Lua with Vim for like 20 years or so, and you can use it to write perfectly functional plugins with it. Probably the main difference is that in Neovim Lua is always guaranteed to be available, which isn't the case for Vim.

One of the big ones for me was Wayland support in neovim-gtk (https://github.com/Lyude/neovim-gtk), which therefore, unlike gvim, fully supports fractional scaling.