I think it’s kind of crazy that vim9script is even a thing, especially when neovim has proven how much more viable lua is as a scripting language. Lua is way more beginner friendly than vimscript or vim9script, with luajit you get killer performance, lua has an awesome language server implementation, it’s a saner programming language imo and so much more going for it. There’s even transpilers to convert typescript / other languages to lua. There’s plugins written in lua today that just wouldn’t be possible in vimscript or vim9script script.
Vim9script on the other hand seems like an exploration in PL, which I’m all for generally but not in a software like vim. Like, just imagine writing and maintaining something like magit or org mode in vim9script. It’s a large complicated piece of software, you'll have to write it using without any linter, formatter or language server (at least for the foreseeable future) and your skills are not transferable to any other tool. Just the sheer probability of better plugins existing and thriving in your ecosystem drop significantly once you choose to have vim9script as the scripting language. I’m curious to see how this all pans out but I’m not optimistic.
The worst part is that it doesn't appear that existing plugins will work in vim9script. Even the syntax for commenting is different:
set number " This is a comment in vimscript
set number # This is a comment in vim9script
Vimscript is like regex: no matter how long I write it I still don’t bother trying to read it. If something isn’t working I usually throw a good portion of my config away and start from scratch.
I’ve been using neovim for a while now but just switched my config over to Lua yesterday. I’ve never seen a line of Lua before yesterday but I _already_ find it way easier to write than vimscript—which I’ve been writing since the early 2000s.
Was there some reason why Bram didn't go for Lua adoption, and instead opted for his own language? Is is the NIH syndrome only? Lua seems just a really good option as far as embeddable languages go. People love complaining about minor issues with it like the 1-based arrays, but building a new language from scratch is just not worth it, no matter how you look at it. Maybe I'm missing something here.
You could ask the same question about why he decided to make the async api and terminal mode incompatible with existing equivalents in neovim. Sadly, the ecosystem seems to be splitting more and more between vim and neovim.
Those patches were broken to begin with when submitted to Vim, and never got fixed until NeoVim was forked out of the blue. People generally don’t know the details of this, and blindly blame Bram.
> building a new language from scratch is just not worth it
Seems this has been said about every single language ever (except the first I guess?), even languages as Golang and Rust have gone through a phase where many question "why even build a new language when X does Y and Z perfectly fine already?", and then they end up really popular anyways as they solved some slice of problem(s) is a particular way that many like.
For every golang and rust, there's probably tens or hundreds of programming languages that will never end up popular. I guess that is to say the probablity that vim9script will succeed isn't high.
And golang initially started off as a replacement for C, and then pivoted because they couldn't achieve that purpose ... now, it's touted for simplicity. When Rust was a pet project of Graydon, it looked VERY different to what it is right now. My point is that vim9script as it stands right now doesn't solve any real world use case that lua wouldn't be better suited for. Maybe vim9script will be better for something else entirely in the future, and that will be, as you describe something people may like. But right now we don't even know what that is, and surely that can't be a reason to decide to go explore language design in such a large community such as the one vim has? It is definitely Bram's right to do so, but I fear that people will rather move to neovim or vscode or emacs than learn and write vim9script, and as a user of that community I think that would be bad.
Also, it's not like people were proclaiming vimscript was awesome you know. There's a talk from one of the core devs of vim-lsp on YouTube [1], on features of vimscript, and literally in every slide the presenter caveats the vimscript feature in one way or another. I find it hilarious, it's a perfect example of the frustration of when writing plugins with vimscript.
I think there is a big difference between designing a new freestanding language vs one designed for extensions/plugins. The freestanding languages are free to iterate and incorporate novel, wacky ideas. An extension language should do the best it can to avoid rocking the boat.
I have a dear place in my heart for tiny focused languages and think if Vim had stated they were going to suddenly make Wren, Gravity, Janet, etc first class languages, there would be less reluctance than a new thing.
Nate's Law says, "Only an idiot expects anybody to use their new language". First corollary is "All new languages are designed by idiots".
Very, very rarely, lots of people find reasons use a language designed by (such) an idiot, anyway. We are lucky when the language is not terrible, because how good it is even more rarely affects whether it will take off.
In practice, languages almost always ride to popularity on the back of something else. C rode Unix, C++ rode C, Java rode Sun Microsystems' $billions and the promise of getting off Microsoft's framework-hell treadmill, C# rode .Net, Javascript rode HTML (and then web services because the same people were coding both, at first), Go rode Google and Docker. Lua got where it is by being really easy to embed, and being simple, powerful, not weird, and (lately) fast.
Python got there mostly the hard way, but also by being easy to embed and to extend with C ABI-compatible plugins, despite being weird and extra-super-slow.
Amazon, BTW, might be unique among IT behemoths in not hustling its own walled-garden language. (Or maybe I just don't know about it.)
I think there is some concern among some people in the rust community that amazon will gain more influence over the steering of rust to guide it towards it's own walled garden.
I don't share that sentiment and I personally think that as amazon adopts rust it will gain rust community principles. But I'm probably wrong.
I don't think making a new language is so much more crazy than making any other piece of tooling. Obviously, it's going to have to have compelling advantages to convince people to move from the tools they know and love. But, if you're putting in the time, you probably imagine you have some compelling advantages. Rust is an obvious example of this, as is something like Java, or C++.
I think you're underselling Java and C++. The JVM idea is clever because it means you do all the portability stuff as part of the language, rather than asking programmers to do ifdefs for every platform. Making it a safe, memory-managed language is clever because most programmers don't care about the performance hit, but they do care about the bugs.
C++ has equally compelling advantages. If you write less code, you get less bugs, and more work done at less eyeball-hours. If you can do that 'zero-cost', with abstractions, a lot of people who care about performance are going to find that really exciting.
Rust basically continues this pattern.
Obviously you have to sort of win the lottery as well, because you need enough people to bring the language from clever-research-project to useful industrial tool, but I think the fundamental point is that successful languages have both luck, and a killer feature.
I imagine all of these languages will sink out of sight at some point, because it's just clear that as a culture we're in the very early days of living with computers, so these languages are a bit like bone needles or flint axes. I still think the innovations contained in them will go on to inform future development.
Yes, if you compare their functionality, performance and on a bunch of other attributes sure. But I'm not doing that, I'm comparing them on the attribute of "new programming language", which all of them have been at one point or another.
It might just have been that Vimscript didn't go the way it was intended to, or people moved towards different paradigms to doing modal editing in a sane(r) way, but maybe in some alternative universe, Vimscript became a popular scripting tool.
I don't know about the timeline of Vimscript in particular, but seemingly Vim was first released in 1991 while Lua first 1993, so by the first release of Lua, Vim already existed by then. Not sure when Vimscript appeared though.
On other trends (Google Trends to be specific), search volume for Lua only became larger than for Vim in 2004, with Lua hitting it's peak in 2009. Search volume for Vim would have been much larger before 2004 if we had a single search engine everyone could have used, but hard to know in afterhand I guess.
vim9script was most definitely written way after lua was integrated into neovim, and well well after lua was popular as an embedded programming language choice. While it is plausible that the idea for vim9script was conceived without him knowing Lua was a choice, it is unlikely that work on it was started without Bram knowing. There's even people that have commented on the google groups as far back as 2016 about neovim's use of lua. It's unlikely that Bram wouldn't have seen that.
vim9script, though, is the evolution of vimscript, and has some amount of backwards compatibility, short-ish migration guides, etc. Initially choosing an embedded script language and migrating to a new one are fairly different scenarios.
Vim already could be compiled with Lua, Ruby, Python with their own respective vim APIs. How is it possible that he didn't know he could use an established programming language for scripting?
Lua and vimscript are both the same age; Lua came out in 1992, and vimscript in 1991, so it would not have been an obvious choice. I think that vimscript has the same problem as shell scripts: there are a lot of editor/shell commands, and they didn't want to introduce a special syntax for distinguishing between the language proper and the editor commands.
I don't think that vimscript is that bad. What i don't like about are the scope rules, i.e. special prefixes for function arguments, locals and globals. Also the call keyword is required for function calls and let keyword for assignments.
Anyway, Python can be used as a vim extension language, i am not sure if Lua is superior in this respect to python.
What would cause such a performance difference? I thought that both lua and vimscript were interpreted languages. (asking as a long time vim user, really curious about it)
Interesting. With java the just in time compiler starts to work, if you have iterated several thousand times over the same spot (java cmd line option -XX:CompileThreshold sets this, the default 10000 by default for hotspot server) Interesting if lua has a similar thing... have to learn more about it.
JITs are more-or-less portable now. Lua's, like most, probably came originally from some Javascript's. But of course they all trace back conceptually to HotSpot in the '90s. Even Guile Scheme is JITted now, though it probably shares no code with the others.
The term "JIT" is getting abused lately to describe what happens to users' eBPF code that runs in the Linux kernel, and Wasm that runs in browsers. In those, all types are known statically, code is compiled to a portable form offline, and transcribed to machine code before any execution, and none of the runtime instrumentation, analysis, and progressive rewriting occurs.
I think he does not like to go with the flow, but instead implement things the way he thinks best suited and best performant with Vim. I don't think he cares about NeoVim.
Vim started in 1991. I don't know when VimL became a thing, but there's a serious possibility that Lua wasn't a great option at the time, and the only established embeddable language might have been some lisp or Tcl. I am not super versed in this area though.
Perhaps neovim isn't the Truth to which we all aspire, or care about. Certainly there are many, many ways to do things that are not newovim. If someone chooses one of those ways, 'why didn't you use neovim's way' isn't a serious question.
(Can we stop hijacking Vim threads? Submit a FPP about neovim.)
Let's be realistic: If people were really concerned with some issues with Vim9Script, they could address them in nearly infinite ways. Yet they choose neovim, again, and as some standard of truth or excellence (where else is neovim a standard of excellence for anything?).
Every Vim discussion has neovim people finding ways to attack Vim. The signal is always negative which makes the signal meaningless - the source is just tuned to transmit negative.
It's a major reason I don't consider neovim. Who wants to be involved in that community, defined it seems by hating someone else's hard work - which they are giving to the public for free - and being parasites on the other's reputation. Just do your own thing, in your own way, and do something wonderful - don't worry about criticizing others. Ugh.
I have to say that I love vim, and super respect Bram and all the other contributors for everything that they have done for vim.
There just happens to be some technical choices in vim that I don't agree with / don't find appealing, where neovim happens to have made an alternate technical choice that I do agree with / find appealing. vim9script is one of them, which is highly relevant to the submission. I apologize if I came across as hating someone else's hard work.
My point isn't about being concerned about a specific issue with vim9script per say, it's vim9script itself. If Bram and a bunch of core vim devs were spending time on their _extremely_ valuable time on anything, the last thing I'd want it to be would be a vimscript offspring. That is just my opinion, and that is truly the extent of my opinion. Again, I apologize to Bram and the core devs if that came across as anything else.
I have used vim for more than 10 years now (neovim for just 2 of those years), and I expect to be using vim / neovim for the rest of my life. And having written some useful but niche plugins for vim, I felt like expressing my opinion here about the direction of vim / vimscript / vim9script wasn't unreasonable.
The only person I'm seeing here as a reactionary is you.
I love vim. I'm using neovim a fair bit now, too. How wonderful is it to be spoiled for choice?
I think it's great we have two vibrant lines of *vim development and the opportunity to learn the best lessons from each. Here, I think it's a bit of a bummer: neovim has proven lua to be pretty decent (as much as I dislike lua itself) and this would have been a decent place for vim itself to consider following.
As a result, we're going to have a plugins/scripts ecosystem that's more fragmented than it needs to be. Meh.
I haven't seen what you're saying. I've seen people addressing specific problems, and suggesting specific solutions, and I really don't understand why neovim isn't a reasonable suggestion. Maybe you can point out some of these unreasonably negative comments for me.
Neovim is literally people doing their own thing in their own way and succeeding. I don't understand your concerns or why you don't consider a solution to this problem to be viable just because it acknowledges the problem as a problem. Sounds a bit kafkaesque to me, to refuse to consider a solution because even bringing up the problem is considered too negative. How should neovim have done it? Do you think they should simply not have bothered?
I‘m neither pro nor against VIM or NeoVIM, but your comment is imo completely negative and not helpful at all.
I for one are glad for NeoVIM improving upon VIM and pointing out some weaknesses.
Since NeoVIM was released, Bram has been improving VIM much faster than before and even added features like async I/O support, that he previously rejected.
I've avoided neovim because my current vim setup justworks™ and i trully depend on it for being productive on my job. As time goes by i really feel like i should switch based on how the two projects progress. Do you know of a resource that could hold my hand?
Well in theory everything that works in vim will work in neovim (there's a few exceptions[^1]). So you really don't loose anything by installing neovim and using your same .vimrc for it.
You can start experimenting with Lua and the new plugins whenever you're able to.
When I switched in 2018 my config essentially just worked, I had to replace a plugin that no longer worked but everything else went smoothly, the process took about ten minutes.
Err unless something has changed, everything that works in vim8 should work in neovim. It was a drop-in replacement for me. Nothing new to learn unless you're a plugin developer.
The exception is the async API which was first implemented by Neovim, but Vim followed with something incompatible. Most plugins that need it are compatible with both though.
I've been using MacVim for 15 years; it has been pretty much solid the entire time, and I'm used to its mouse integration. When I started out, I was doing a lot of cross-platform development and there was a Windows version of Vim which behaved almost the same. It was great to have a powerful text editing experience which was pretty much the same everywhere.
I tried out NeoVim, but as far as I can tell, it seems to be terminal-only/keyboard-only? I can use Vim keyboard-only (certainly I do that all the time over ssh), but it's not my preference.
My second choice for editing behind MacVim isn't NeoVim but VSCode, but I don't use VSCode with Vim bindings because in my experience grafting Vim bindings onto any editor not Vim won't be feature complete. In a perfect world, there would be an IDE which is truly a Vim-style modal editor at its core.
I just started looking into Neovim, and I had the same concern about it being terminal-only. But then I saw this on the Neovim site:
"Graphical interfaces are not packaged with Neovim. GUIs are not limited by terminal capabilities and can choose to override the rendering of certain neovim elements (cursor, tabline, popup menu, etc)...See Neovim's wiki[1] for a list of many of the available GUIs."
> This extension uses a full embedded Neovim instance, no more half-complete VIM emulation! VSCode's native functionality is used for insert mode and editor commands, making the best use of both editors.
I like lots of things about VSCode, but there are inefficiencies with editing that just drive me bananas so I keep falling back to good old familiar MacVim. For instance, line wrapping, auto-indenting, and mouse-select-then-rewrap in comments — comment support in the Vim ecosystem seems to have been designed by and for people who really care about good documentation, while I have to work much harder to get my comments and docs to look good when editing with VSCode.
Hopefully the mechanism of embedding a full NeoVim instance will allow for a moe-or-less feature-complete Vim editing experince.
There is also Onivim although it is not 1.0 yet. Development is financed through selling licenses but it is open source and you can build it yourself. Development has stalled when the main dev got a job some months but there are apparently still people willing to develop it.
Oni2 is not vim. It does not act like vim. It uses neither Vimscript nor Lua, but instead Javascript (VSCode-based extensions).
I paid for an Oni2 licence and regret it, because it isn’t what I want, which is a MacVim.app wrapper for neovim.
If you like MacVim.app, there is _absolutely no GUI that is acceptable_ for neovim. I understand why, and I’m not interested in taking on the development myself. But until someone makes a GUI that is as well-integrated with macOS as MacVim.app, I will be using vim and not neovim.
In addition to the fact that there are guis for neovim, neovim in the terminal does support mouse interaction as well (assuming your terminal emulator supports it, which should be the case for most modern terminals).
I just tried out nvim in the MacOS Terminal, and a couple of things didn't work right away.
First, clicking on a location didn't set the cursor. Especially when editing large files, I like to scroll in MacVim, click to set the cursor and then start typing. While I can do things like note the line number and jump, or scroll by moving the cursor with key commands, I find those less efficient.
Second, selecting text using the mouse didn't produce a selection that Vim knew about. I use this feature all the time in MacVim, to produce a visual selection which I then rewrap using `gq`, filter by piping the selection through an autoformatter like `rustfmt`, etc. Again, I can do this using keyboard navigation exclusively to make visual selections, but I find it easier to select using the mouse.
Interesting, all of those things work for me with alacritty, kitty, gnome terminal, etc. Maybe it is a limitation of MacOS Terminal? Or you need to explicitly enable `set mouse=a`?
This seems to be something in Vim rather than a NeoVim-specific setting, as I tried the same thing with the standard Vim and it worked the same. The scrolling feel in the Terminal isn't as smooth as MacVim, but it's still pretty good.
Yeah, there are a bazillion UIs (and most have stopped being updated) but nothing that comes with like vim/gvim. I might have looked at neovim if there was a neovim/gneovim but that isn't the case. I am okay with Lua. I am okay with Vimscript and Vimscript9. So neither of those is a pusher for me.
I've just installed it and started playing around.
On first open, a lot of the interface was unreadable because VimR seemed to be assuming a dark background, but I use a white background. `set bg=light` didn't fix it. `colorScheme=PaperColor` fixed it incidentally because it didn't find the color scheme and reverted to something legible, haha.
Next, I tried to set the font size for the navigator to something bigger because my eyes aren't that great. Although I can use `set guifont` to set the editor area font, the navigation area doesn't change. Presumably there's some way to fix it, I just haven't found it yet.
VimR looks cool and I really like having the navigator there IDE-style, but it seems like there will be a period of adjustment. Nothing new for someone accustomed to Vim, haha.
The main IDE-style features I've been going without in my ordinary day-to-day editing with MacVim are the autocompletion, suggestion, and hover-to-show-documentation. (I've started using ALE which is helpful but needs some tweaking before it's really usable.) It might be possible to get those with either MacVim or NeoVim, and it would be worth the configuration to set them up if so.
Have you tried coc? Despite the repo name it works with regular vim too and is definitely the easiest way to get completion and other LSP functionality (jumping to definitions, doc previews, error highlighting etc).
I have set up a complex neovim configuration, but I don’t use it.
Why? Because there’s not a _single_ neovim client that is as good as MacVim.app. I paid for Oni2 (I regret that; it’s _not_ a vim replacement). I have contributed code and time to helping a couple of other GUIs fix their issues. But they are all crap compared to MacVim.app.
Until that is fixed, I don’t think that there’s a good reason to consider switching.
I tried it. For various reasons, it isn’t _quite_ there.
It doesn’t build a .app bundle, which means that it can’t have a proper distribution with appropriate signing &c. that would give it access to various macOS features. It doesn’t have a menu (which _does_ matter).
It doesn’t have a "release" build since May 2020, meaning that the only way to get a meaningful build is to build it yourself (not a big deal, but still).
I have the same setup in both vim8 and neovim. It's symlinked over from neovim, because I like the xdg ~/.config dir better, keeps things tidier. Basically pathogen, lightline and vim polyglot. I use vim8 most if the time out of habbit. I like Lua better but I understand it has poor handling of strings and I don't know how that fares with and editor extension language.
> it has poor handling of strings and I don't know how that fares with an editor extension language.
I guess the parent refers to Lua treating strings as simple byte arrays, whereas a text editor has to deal with characters in various encodings, some of which can be multi-byte.
Similar thoughts with me - Why can’t Vim just support lua scripts as Neovim’s way? Neovim can then omit the heredoc hack for lua scripting. And plug-in devs and vim users should be happier ass well.
This is not a breaking change. Everything that works on Vim8 script will continue to work. The new scripting language will provide extensions that you can use to get better speed.
> I would have loved for Vim to also adopt Lua
Vim has supported Lua for a long time. Anyone who wants to really use Lua for Vim plugins already has the option of doing so.
> Vim has supported Lua for a long time. Anyone who wants to really use Lua for Vim plugins already has the option of doing so.
How does that compare to writing Lua plugins for Neovim? Seemingly all search results for "write vim plugin in lua" are dominated by results for writing lua plugins for neovim. Does vanilla Vim have something like Neovim's "Remote Plugin" or how does it work?
My understanding is that neovim devs would like to see a lua interface in vim, but right now there's a lot of functions in neovim's lua interface that are not available in vim's lua interface.
But for the stuff that is available, you can either use the vim help to learn about it or search on vim's github issues / PRs, e.g. https://github.com/vim/vim/pull/7959. I'm curious if there are other ways to learn more about vim's lua interface, searching on google as you said does not give great results for vim, just neovim.
This is a perfect example of NIH (Not Invented Here).
So you have the huge success of first-class Lua support in Neovim, and it's clear that there is a very real need for a better scripting language in Vim.
But not only do you skip Lua, and lose out on the work and plugins that has already been done, you decide to write yet another custom scripting language.
They said "huge success". Huge successes in text editors are Vim, Emacs and maybe Sublime. And do you have anything to backup your claims about neovim's popularity?
One measure is the number of stars on github and active contributors 49.7k vs 25.7k and 737 vs 79. The other measure can be the number of new extensions being written for each of them (particularly extremely high quality ones like telescope). Searching `nvim` on github yields many plugins which are advertising the Neovim editor by having it in their name, some of these are even ones which support vim e.g. Shougo/denite.nvim all of which point to the fact that neovim is a huge success and is on tract to overtake vim. It would not be an exaggeration to say that a lot if this is due to first class lua support in Neovim. By adding nice features like treesitter and LSP it has become an improved version of vim, an editor that actually understands the code being edited beyond simple text objects (e.g. https://youtu.be/E4uaPs9e9UU?t=68)
This looks great. Some takeaways from looking into the documentation:
They're promising 10x - 100x better performance (since vim9script is typed and will be compiled). Also -- you can mix vimscript and vim9script in a function, a file, or a module. This will let legacy modules or scripts stay mostly the same but port some of the slower-running bits to vim9script to gain the benefits without a giant effort to port the whole thing.
What happened to the orphanage in Uganda? Not a criticism, just curious about the change. It's fantastic that Bram uses Vim's platform to lead and encourage others to support those in need.
More or less furthering the gap we all knew was coming at one point or another (opinion from former Vim user but current Neovim user). Neovim ecosystem mostly write plugins in Lua by now, and most new Vim plugins will probably require something from Vim9 Script at one point.
If I had to guess: someone will eventually build a transpiler/converter of some sort, most likely vim9->Lua (assuming my guess that vim still has more users than Neovim).
This is great news. I think Vim9Script is an excellent language. Just the fact that it will help speedup existing scripts is going to been a boom for Vim usage and plugin development.
I should start by saying my Vim config is reasonably minimal, but I'm highly skeptical of this making plugins noticeably faster. How much time are plugins spending executing Vimscript vs executing external tools?
I don't believe it'll speed up existing plugins though. If I remember correctly, vim9script is akin to an entire new programming language. Heck, even the syntax for comments has changed.
set number " This is a comment in vimscript
set number # This is a comment in vim9script
There's going to be a LOT of porting of existing plugins for this to all work.
The vim scripting language is an extension of the command language used interactively in vim, so it does make some sense for the transferable knowledge.
I feel like vim should really be focusing on other, less shiny things. Users that primarily want a shiny editor are already using VS code and the like.
Vim9script on the other hand seems like an exploration in PL, which I’m all for generally but not in a software like vim. Like, just imagine writing and maintaining something like magit or org mode in vim9script. It’s a large complicated piece of software, you'll have to write it using without any linter, formatter or language server (at least for the foreseeable future) and your skills are not transferable to any other tool. Just the sheer probability of better plugins existing and thriving in your ecosystem drop significantly once you choose to have vim9script as the scripting language. I’m curious to see how this all pans out but I’m not optimistic.
The worst part is that it doesn't appear that existing plugins will work in vim9script. Even the syntax for commenting is different:
See https://vimhelp.org/vim9.txt.html#vim9-differencesAnd to get any performance improvement, plugin authors will have to do a LOT of work that is not compatible with their existing plugins.
I for one am glad neovim exists, and I encourage people to throw a few bucks their way :)
https://github.com/sponsors/neovim