I use nvim in the terminal and gvim/macvim on the desktop. I don't like how the nvim community seems to be throwing themselves wholeheartedly into lua and lua-only plugins (vimscript plugins are better because they work with both vim and neovim). Switching to init.lua also means losing all compatibility with vim, and I cannot fathom why people would want to do that considering that there is nothing that init.vim cannot already do.
I also don't like how there looks to be an upcoming split in the plugin community when Vimscript 9 releases and the neovim community will ignore it while plugin authors in the vim camp (e.g tpope) may start moving their plugins over to it.
That said, the built-in LSP for nvim is very good thing and I plan to migrate away from the node-dependent coc.nvim once nvim 0.5 releases.
> vimscript plugins are better because they work with both vim and neovim
I think you mean "vimscript plugins are better for plugin adoption because they work with both vim and neovim".
From the language-design, performance, documentation, robustness/general codebase quality, and total number of users perspectives, Lua is overwhelmingly better than vimscript.
> I cannot fathom why people would want to do that considering that there is nothing that init.vim cannot already do
Ahh, yes, the Turing-equivalence fallacy: "technology A is theoretically capable of doing everything that B does, therefore they're equivalent". Brainfuck and Python are Turing-equivalent, and yet nobody would seriously argue that they're interchangeable.
Well, yes. Vimscript plugins will see better adoption. Lua matters for compute-heavy plugins.
> Ahh, yes, the Turing-equivalence fallacy: "technology A is theoretically capable of doing everything that B does, therefore they're equivalent".
Language design is not the full picture. init.lua is essentially a thinly-veiled init.vim with lua syntax. You will have to learn init.vim either way. It is extra work to do something in init.lua, and in using it you remove any chances of it ever working with an installation of vim (e.g. vim still has the best GUI options out there).
> From the language-design, performance, documentation, robustness/general codebase quality, and total number of users perspectives, Lua is overwhelmingly better than vimscript.
Even if ahead of Vimscript; from the language-design, performance, documentation and total number of users perspectives Lua sucks very very much.
> I don't like how the nvim community seems to be throwing themselves wholeheartedly into lua and lua-only plugins (vimscript plugins are better because they work with both vim and neovim)
How many decades do we continue to use, support and maintain a terrible DSL like vimscript? I personally don't want to be using vimscript in 2030.
The thing is, Vimscript sucks. Using a more mainstream language would be great for a modern advanced editor.
Vim has a ton of Vimscript plugins but I wonder how long it will take the Neovim community to replicate most of their functionality in Lua. I'd guess that not that long.
I spent 10 hours learning enough vimscript to make a command to check if a line is commented, comment it if not, or uncomment if it is, be able to handle multiple filetype and comment chars, and be able to handle proper indentation and multi-line selection.
I have to imagine it would be simpler in other languages. Vimscript is hard.
I'm sure mine's strictly worse. It was written when I was working in an environment where it was easier to spend 10 hours on something than it was to get permission / access to download vim plugins from the internet.
government contractor, yeah. It is insane how much effort there is put into getting butts in chairs for the right number of hours and how little effort goes to actually building something useful.
I’m pretty sure that the primary reason we don’t have more VIM plugins, despite many more emacs users, is vimscript being terrible.
If vim had a more usable scripting language it would have easily surpassed emacs in plugins and more importantly, since plugins would have been more popular, vim would have been developed in a way to make it more extensible and nvim wouldn’t even be needed.
I think you are correct. I think this is why certain Vim "demigods" have arisen (aka tpope). Only a few take the time to learn VimScript. In my humble opinion, when I took the time to try and learn it a while back, I ascertained that it was not worth my time.
Having never written a line of Lua in my life, on the other hand, I was able to pick it up in exponentially less time than the small bit of VimScript that I "know". Lua is not a fantastic language, but it is infinitely better than VimScript.
The philosophy of vim is to be able to do a lot without the need for complex plugins, as opposed to emacs' world view. That's why vim script is good only for simple scripting tasks.
I think emacs having more plugins is a consequence of its design and philosophy, not the extension language itself. After all, emacs lisp is not the best language in the world and only a small group really knows it beyond the basics.
> emacs lisp is not the best language in the world
Emacs-lisp is a Lisp. It may not be the best of Lisps, but even a bad Lisp can be far more powerful than many other non-lispy languages. To understand what makes Emacs so awesome, one has to understand the philosophy of Lisp. Emacs Lisp is not just a text editor, IDE, email client, project management tool, scientific calculator, etc.
Emacs, first and foremost is a Lisp environment. Definitely not the most ideal, but certainly the best one we have today.
> I think emacs having more plugins is a consequence of its design and philosophy, not the extension language itself
I believe, Emacs held the crown of "the most malleable" tool for over forty years, specifically because it builds on top of Lisp.
Number of plugins is not an indicator. They also have to "play nicely" with each other. I just checked - I pull over four hundred Emacs packages in my config, including built-ins and dependency libs. I just cannot imagine any other IDE or text editor with 400 plugins installed. That's just not possible.
Emacs lisp is not a bad language, but it's also not the reason for the existence of Emacs. It is the other way around: it was Emacs that created Emacs lisp. Initially, emacs was created on top of TECO, arguably the worst, most difficult programmable editor ever created. TECO language was so bad that they decided to switch. But emacs, the editor, was successful even running on top of a terrible language that nobody liked at the time.
> Emacs lisp is not a bad language, but it's also not the reason for the existence of Emacs
Early Emacs and the modern GNU/Emacs I think, are two distinct worlds.
I believe Lisp has shaped Emacs into its modern form.
I just can't imagine the possibility of building something like Org-mode, with the same level of extensibility and flexibility in any other language that is not a Lisp.
I bet if you ask any serious Emacsen - authors and maintainers of Magit, CIDER, or any other serious Emacs package if they could replicate their work, for example, in Python. I have no doubts, they'd definitely say: "that's nearly impossible"
Magit is not just a user interface. It's also a number of emacs-lisp packages useful on their own. It's Transient that's gaining popularity for building modal key UIs in Emacs. It's Forge that paved the road for nice packages like github.com/anticomputer/gh-notify. It is Org-mode integration and many other things.
What you're using is a ported subset of them.
There are always multiple paths to get something done. Some people prefer automation. Having "a bucket of bolts and nuts" makes it possible to hack your way around things.
Some people like Ferrari. For some - the utilitarian value of it, is minimal. They'd rather have "a bucket of bolts and nuts" instead. They can't go camping in a Ferrari. They can't take their bullmastiff to a vet in it. They can't help a friend to move furniture.
Emacs is that - it's not akin to a shiny, expensive but not very useful car. It's like a transformer - you can build a pickup truck, a camper, an ambulance, or a race car.
But some people like Ferrari. And that's totally fine.
There is a point when it doesn't make any difference if the language sucks or not. What matters is if it is capable. You can say the same about most successful languages: C sucks, shell script sucks, eLisp sucks, LaTeX sucks, but they're all there and will continue to be because they have been capable of support the communities for which they were designed.
Now, you can freely dream about the perfect extension language for UNIX, or vi, or TeX, or emacs, but it won't make any difference because nobody will move from something that works to an unproven extension language just because some people (usually the minority) feel that it is a more comfortable language for them.
> Now, you can freely dream about the perfect extension language for UNIX, or vi, or TeX, or emacs, but it won't make any difference because nobody will move from something that works to an unproven extension language just because some people (usually the minority) feel that it is a more comfortable language for them.
Lua ia an extremely powerful and popular extension language. It probably has at least 10x the users that Vimscript has.
And people willingly choose Lua. Barely anyone chooses Vimscript, they're generally forced to use it.
If anything, Vimscript is the <<unproven>> extension language. It's in Vim because Bram made it the Vim language, but it was never voted on or designed. Vimscript will most likely die with Vim, because I'm quite convinced that outside of trolling attempts, no one will adopt it for another app ;-)
Which is just fine! Vimscript was created to create simple vim scripts, not to build full programs.
And if you need to do more than Vimscript can do, Vim already provides this: it has native bindings to Lua, among other languages. If Lua was such in demand to write vim scripts, at this point it should have taken over VimScript as the main extension language, but it hasn't, and I guess that unless something huge happens in the community, it won't.
As someone who maintains a vimscript plugin... HAHAHAHAHAHAHA
There's API differences between vim8 and neovim that make it a pain to do certain tasks on both (UI manipulation or anything with asynchronous work). Supporting both in the same plugin is annoying. The split is already there and it's only going to get worse, so might as well go with a language that doesn't suck to write. I think upstream vim is the one needing to catch up. Vimscript sucks to write and maintain.
> I also don't like how there looks to be an upcoming split in the plugin community when Vimscript 9 releases and the neovim community will ignore it while plugin authors in the vim camp (e.g tpope) may start moving their plugins over to it.
Honestly Vimscript 9 always felt like a serious case of "not invented here". Bram could have easily chosen one of many existing languages, but instead decided to take Vimscript and make it even more bizarre (this was even more so the case at first as IIRC block delimiters for example were really odd).
Setting that aside, you could also argue that people moving their Vimscript plugins over to Vimscript 9 is a problem on their end because it makes the plugins incompatible with NeoVim. In other words, the argument is basically silly.
I've always wanted to write Vim plugins, and as soon as 0.5 hits stable, I'm looking forward to trying! I won't touch VimScript with a 10-foot pole, and I write code for a living. It's not worth my time, and it does not commute to other things that I'd rather be spending my time coding.
I don't have experience with Vimscript, but I know both Lua and Python. It seems that the biggest benefit is gained by stepping up from Vimscript to any of those two. Switching to the other would only have diminishing returns, if at all.
Apart from that, Lua was explicitly designed to be embedded. Python is designed as a scripting language that can bind to C code, and embedding seems to be an afterthought.
This is demonstrably and unequivocally untrue. Lua is designed to be fast, lightweight, and easy to use as an embedded scripting language. Python is a general-purpose kitchen sink language. Python is 10x bigger, and 10x slower than Lua. It is bad fit for an embedded language.
How many people realistically are willing to write vimscript plugins, vs how many people realistically are willing to write Lua? I know personally, after wresting with vimscript for a couple of days I'd never touch it again, but Lua is nice.
In a vacuum where there was no need for legacy vim support (lets say vim integrated lua), I can't imagine anyone but a small minority preferring vimscript over lua. My argument isn't that nobody programs vimscript, it's that hardly anyone does it by choice.
> I don't like how the nvim community seems to be throwing themselves wholeheartedly into lua and lua-only plugins
The transition to lua can't come soon enough, imho. The biggest downside to vim is vimscript. Lua is a delightful little language and the sooner it replaces vimscript the better.
Replacing init.vim with init.lua is, imo, a mistake. Lua is not a config language. I'd sooner use bash. Once you start writing functions tho lua feels more sane.
I recommend checking out gui frontends for nvim on desktop. I've been using neovide[1] for a while now and it's decent. I also found out that you can use nvim as a backend with the vscode-vim plugin which will load your nvim config and scripts.
I also don't like how there looks to be an upcoming split in the plugin community when Vimscript 9 releases and the neovim community will ignore it while plugin authors in the vim camp (e.g tpope) may start moving their plugins over to it.
That said, the built-in LSP for nvim is very good thing and I plan to migrate away from the node-dependent coc.nvim once nvim 0.5 releases.