1. 24
  1. 8

    I have not explored Vim9 script, so I don’t know how hopeful or how sad to be about the language itself. The documentation promises potentially significant performance improvements: “An increase in execution speed of 10 to 100 times can be expected.” (That said, like many people, I would much rather write scripts for Vim in Lua or Python. But maybe Vim9 script will improve the syntax as well as the performance?)

    But I do worry about this causing a significant rift in plugin development since Neovim has support for Vim9 script as a non-goal.

    1. 6

      The rift is already there. In the latest release Lua is pretty much first class and many plugins have already jumped ship and become NeoVIM only. I don’t expect Vim9 to open the gap much wider than it already is, and if it does (for example if Vim9 only plugins start having hot stuff people don’t want to live without) it would not be surprising to see that non-goal be removed. After all they have kept up pretty well with vimscript support and porting VIM patches in general.

      1. 6

        Agreed. After neovim 0.5 I would need a really good set of arguments to move away from neovim and the thriving plug-in ecosystem using lua

        1. 2

          I could see pressure growing for vim9script support, but on the other hand, many may just author stuff in the legacy scripting for cross-compatibility because neither vim9script nor lua are necessary.

          I do hate to see this rift for code that needs the performance or flexibility though. It’s been pretty annoying for years where the core of an addon will be implemented in a pluggable scripting language and you have to make sure that’s feature-enabled and available and they’re all picking different languages. I’m disappointed that vim9script is becoming just another one of these, just without the external library dependency, and for now, definitely not available on nvim. It sounds like enough of a pain that I’d stay legacy, or do an IPC model like LSP, for compatibility, or just decide compatibility isn’t my problem.

          I think if vim9script takes off it will be through the sheer weight of vim’s popularity compared to nvim and people not concerned about compatibility, or willing to maintain two or more copies of the same logic. But I’m also not sure it’ll take off and I would’ve liked to see first-class lua in vim too. Just static linked, guaranteed in the build would’ve been enough for me!!

          Anyway, maybe it’s sad-but-okay if it’s just time to start saying vim and nvim are becoming too different. Clearly that’s happened with lua-only plugins.

      2. 8

        For many things TypeScript is followed. It’s a recent language that is gaining popularity and has similarities with Vim script.

        Well, at least it’s getting its inspiration from a good place. Nice to see that we are getting a little type safety.

        Although, one small thing I would not copy wholesale is import syntax:

        import {someValue, MyClass} from “thatscript.vim”

        I think the imported identifiers should come after the module name. That could help with autocomplete, for example.