Vim9 Script Feature-Complete | Hacker News Reader

Vim9 Script Feature-Complete

groups.google.com

103 pointselvis70118 comments

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

See https://vimhelp.org/vim9.txt.html#vim9-differences

And 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

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.

[1]: https://github.com/neovim/neovim/issues/1716

Thanks for all the replies, didn't know it was meant to be a drop-in replacement, will give it a try :)

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

[1] https://github.com/neovim/neovim/wiki/Related-projects#gui

This looks interesting:

https://github.com/asvetliakov/vscode-neovim

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

https://www.onivim.io/

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

Mouse support isn't enabled by default, on any terminal. You need set mouse=a

Thank you, that solves the issue!

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.

You can give VimR[0] a try, I don't know what mouse features you use on MacVim, but that was the most pleasing GUI version of vim/neovim I've used.

[0]: https://github.com/qvacua/vimr

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

https://github.com/neoclide/coc.nvim

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

How is Lua’s string handling supposed to be poor?

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

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.

You could take a look at neovide, it looks promising.

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

It doesn’t render fonts correctly, especially on macOS: https://github.com/neovide/neovide/issues/1096, https://github.com/neovide/neovide/issues/589 (although it may be related to how font names are resolved, https://github.com/neovide/neovide/issues/776; https://github.com/neovide/neovide/issues/1057 seems to resolve it), https://github.com/neovide/neovide/issues/851, https://github.com/neovide/neovide/issues/283.

The last appears to be fixed, but the former two are problematic from my perspective as a replacement for MacVim.app.

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.

Vim and Lua evolved in similar timelines. It's plausible that vimscript was written without him knowing Lua was a choice.

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?

What is NIH syndrome?

Edit: got it, its called "Not Invited Here" syndrome.

not in house.

“Not Invented Here” is how I’ve always known it.

This is the correct one.

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

Go and Rust compared to vim script is an Apples to Space Shuttle comparison.

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.

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.

[1] https://www.youtube.com/watch?v=7fcJWwl1-SU

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

Java and C++ won the lottery. It is far too early to tell whether Rust will, or will sink out of sight, like Ada. History predicts the latter.

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.

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.

My impression is that Bram is trying his best to outcompete neovim.

That goes without saying, and it's just unfortunate that he chooses to compete rather than collaborate

Competition is good, and it’s the reason why Neovim was created in the first place!

I mean, the reason is that those async patches were just sitting in the queue for a year, and by starting Neovim, they could get them in right away.

Then Bram started competing afterwards.

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.

Why did it take neovim being forked to get those patches fixed?

Is there evidence that the fork was the root cause of that action. and not a mere coincidental correlation?

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.

Lua is probably way, way faster. Does that matter? It could matter. It would be awful if it did matter, and you chose wrong.

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)

Lua is JITed nowadays. Python has numerous design gotchas that force it to be slow. (But Numpy manages to work around many of them, and be fast.)

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.

Correction: cpython, the reference implementation of python, does not have a JIT; however Pypy does have one.

It was the result of a poll:

1 - https://groups.google.com/g/vim_dev/c/__gARXMigYE/m/iskHVwgU...

2 - https://github.com/vim/vim/issues/3573

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.

Lua is already a supported scripting language in Vim.

But it doesn't have first-class support like in Neovim.

I hope they will get enough money to hire someone full-time. That would be really awesome. I am proud sponsor of it myself.

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.

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

This is a reasonable question on the discussion of vimscript. Does it make sense to have tool-specific languages like this anymore?

I don't love lua, but moving to a "standard" scripting language has a lot of value.

And neovim proves that lua is viable, so...

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

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

When did he reject? To my knowledge, he didn’t reject anything.

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.

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.

No language where array indexes begin with 1 can be called "powerful".

There is an overview here: https://vimhelp.org/vim9.txt.html

I do question if a breaking change for a custom language is the right way to go.

Built in Lua support in Neovim (with LuaJIT) has done wonders for the plugin ecosystem.

There is a lot of activity, and a lot of pluings with great quality have quickly replaced older ones.

That's no surprise. LuaJIT is fast, much easier to write, has a has a sizeable ecosystem and a good LSP server.

Even an overhauled Vimscript won't be anything more than a odd niche language with worse performance.

I would have loved for Vim to also adopt Lua and the Lua API from Neovim to prevent a complete ecosystem split.

I just don't see how implementing a new language makes sense in this context, except for fun.

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.

Vim's Lua interface is through the remote plugins, so you could look for that.

Really not sure why you would want to though

The best place to learn this is

:help Lua

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.

How do we meaure 'huge success'? The only place I hear about Neovim is on HN, where people hijack Vim threads with it.

Not to join in the lynching, but nvim is stable and healthy in terms of development velocity.

It's not as popular as vim per say, but it's definitely catching up. It's kinda silly to suggest otherwise.

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)

According to the latest Stack Overflow developer survey, neovim is used by almost as many people as Emacs is[1].

By your own definition, Emacs is a “huge success”, therefore I’d expect you to extend that description to nvim, too.

[1]: https://insights.stackoverflow.com/survey/2021#section-most-...

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.

Ah, that's the key part people are missing above, you can opt in on a function by function level.

> help me help AIDS victims -- http://ICCF-Holland.org

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.

AIDS is also a huge problem throughout Africa.

Like I said, I think it's great and important that he's doing it. I'm just wondering what happened to the orphanage.

This seems like a too smart for your own good situation.

Just because you can write a programming / scripting language doesn't mean you should.

There are tons being developed already, why not just adopt one of those.

I support NeoVims decision of going the lua route.

Interested to see how this will impact the plugin community, as the Neovim maintainer mentioned he wouldn't implement vim9script there.

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

TJ (one of neovim's core devs) has already started work on that: https://github.com/tjdevries/vim9jit

Their twitch streams where they work on this are a lot of fun too.

I still prefer kakoune, and using sh as scripting language for it's simplicity.

Kakoune is vi done right. I'm surprised it isn't used more often

I would love to change but neovin is just too useful for me.

There's a Kakoune like text editor written in Rust that is not 1.0 that should worth looking into. It's called Helix https://helix-editor.com/

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.

So is Lua or Guile. No need for a new extension language with bashisms and Java and JS inspired stuff.

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.

Your comment seems to be at direct odds with https://news.ycombinator.com/item?id=29759980

> This is not a breaking change. Everything that works on Vim8 script will continue to work.

So seems it won't require much porting unless people want to do the porting.

You are right, my apologies. Reading through this https://vimhelp.org/vim9.txt.html again, it appears that you can intermix vimscript and vim9script.

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?

So I just did this command for the hell of it, and it worked:

:e https://raw.githubusercontent.com/vim/vim/master/runtime/doc...

vim is cool but it's simply not worth investing time to learn a language that only works for one specific editor.

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.

100+ emacs-lisp users disagree with you.

I wish instead of `endfun`, `endif`, `endfor`, `endwhile`, etc. Vim9Script would have gone with a more unified syntax like curly braces.

I don't write much in Vim script, but what are the implications for my beloved, carefully tended .vimrc file?

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.

Reply on news.ycombinator.com