Hacker News new | ask | show | jobs
by enriquto 1047 days ago
> what is it that outweighs all that neovim has to offer?

You should ask, and answer, the question in reverse. What does neovim offer me, as a regular vim user? I don't see anything particularly interesting for my usage, so I don't have any reason to change. Also, some features are missing (like gvim-gtk, that I enjoy using to edit LaTeX occasionally).

Furthermore, as of today, plain vim has an aura of venerability due to Bram's legacy that neovim cannot match. So I'll stick with vim.

It would make sense to port back some of the most popular neovim features into vim. It is a good thing to have innovative forks that experiment aggressively with new features.

4 comments

> 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.
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.
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?

> 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.

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?

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

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.
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).
I have mainly lua config but just put in some vim files where I put bits and functions that were already written in vimscript.
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 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.
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.