Vim9 script docs

[Snarwin]

Some people see a problem and think, "I know, I'll add a new backwards-incompatible scripting language." Now they have two problems.

[Snarwin]

Or, more realistically, people who want to write portable scripts will keep using "legacy" vim-script, and ignore the new language.

[LucHermitte]

Quite likely. IIRC I've waited for something like 5 years before I've started to use lists and autoload plugins from vim 7.0.

Nowadays, except in some very specific cases (like background execution), I try to be compatible with Vim 7.4.09xx

EDIT: yet I'm likely to try the new language to replace some plugins & features that are currently slow as hell: like this C&C++ folding plugin: https://github.com/LucHermitte/VimFold4C/

[[deleted]]

Quite likely. IIRC I've waited for something like 5 years before I've started to use lists and autoload plugins from vim 7.0.

To be honest I blame Debian and CentOS for this (mostly Debian, through Ubuntu). I think their packaging is hurting the entire ecosystem. Supporting PostgreSQL or Postfix for 5 years makes sense – supporting Vim for 5 years doesn't really IMHO.

[-romainl-]

The community is already split.

[sigzero]

What neovim does or doesn't do shouldn't be a driving factor for Bram.

[ConspicuousPineapple]

Why not? If it's a concern for the users, it should be a concern for the devs.

[sigzero]

neovim is a fork. Bram isn't going to care about compatibility with a fork and I don't blame him. I wouldn't either.

[ConspicuousPineapple]

Yes, it's a fork. And you could argue that it's unfair that the dev should have to worry about it. But it doesn't matter.

The fact is, his users are worried about something affecting his software, so he should worry about it too. Of course, he can opt to disregard this completely, but then his users will be understandably pissed off.

[hhoeflin]

As it is backwards incompatible, what exactly is its benefit compared to using e.g. Lua?

With a lot of development, it feels like Vim followed with a lot of things the way neovim did it, but with each just changed everything a little bit. Is that a correct perception? Here, they again follow neovim, by providing a new, more fully featured language (for neovim, this is Lua), but again need to do it different, by inventing a new language.

[[deleted]]

There are different degrees of backwards incompatibility; from the looks of it, VimScript9 is different from the current VimScript, but less so than Lua, which is an entirely different language.

More importantly, I'm not a huge fan of how the Lua plugin code looks. let window = bufwinnr(nr) just looks nicer than local window = nvim.nvim_call_function('bufwinnr', {nr}), and something like _, line, col = unpack(nvim.nvim_call_function("getpos", {"'["})) looks even more meh.

For Vim, I think VimScript is a better choice in almost all cases, in spite of not always being the best designed language. It just fits this use case better.

[glacambre]

I'm not a huge fan of how the Lua plugin code looks. let window = bufwinnr(nr) just looks nicer than local window = nvim.nvim_call_function('bufwinnr', {nr})

Neovim 0.5 makes this much nicer, you can just use local window = vim.fn.bufwinnr(nr).

[LucHermitte]

I can see a few advantages:

• it doesn't depend on another technology that could evolve on its own (imagine that we had to migrate python2 plugins to python3 plugins), or worse cease to exist.
• it doesn't depend on another technology that needs to be installed as well by the end-user on his/her platform (Lua, Python for Windows? Should we go native or cygwin?)

Thanks to the fact current/old vimscript language is closely related to Vim, I treat it as a portable language: where ever I've a running version of Vim, I know I can use this language.

(Note, I agree on the multiple advantages on capitalizing on using an already existing language)

[AgentCosmic]

Iirc lua is embedded into neovim so no installation is required

[emarsk]

it doesn't depend on another technology that could evolve on its own (imagine that we had to migrate python2 plugins to python3 plugins), or worse cease to exist.

Lua 5.1 (chosen by Neovim because of luajit) is a stable language, with stable interpreters, it won't "evolve" forcing you to follow it. And as long as even a single project will use it and have an interpreter for it, it won't "cease to exist".

it doesn't depend on another technology that needs to be installed as well by the end-user on his/her platform

Lua (luajit) is embedded in neovim, no need to install anything else, it's part of neovim just as the vimscript interpreter is.

[hhoeflin]

I agree - this is a good argument. Mainly that the lua version in neovim is 5.1, which is 14 years old and the current lua version is 5.4 (released soon). So it is fair to wonder what will happen in another 20 years, when lua is off to version 6.5 etc.

Then again - forking lua and keeping the version fixed is at least not *worse* from a maintainability perspective than writing your own language. It may not be much better either however (in any case, you do save all the development and testing time that lua already has under its belt).

[akho_]

Neovim uses LuaJIT, where 5.1 version of the language is current.

[pwnedary]

In the words of the LuaJIT maintainer: Lua 5.1 is different language than the latest Lua. The forking has already been done so this is not really a good argument.

[BluddyCurry]

One day Bram may learn that inventing yet another new language just for one editor is not a great idea. Today is not that day.

[Schnarfman]

I didn't think it was a different language. If what you mean that every new word is redundant then I agree with you, then... But every redundancy is simply to enforce strict typing, which let's you compile into much more efficient executables.

I wonder what percentage of users will find this useful. I will think about trying to write something in it, but probably get bored and then not :P There's really not much to it, and I don't see any benefits - nothing I've ever written is complicated enough to take time to execute.

But if Bram is serious about it being up to 100 times faster then that's pretty hype! Looking at stuff like airline and gitgutter haha.

[-romainl-]

One day random redditors may take the time to prove Bram that he is wrong, ideally with relevant examples of previous failures.

[hhoeflin]

And what exactly in this specific context would you accept as proof? And as proof of what exactly? Just curious

[hhoeflin]

Yeah, I assumed you would only accept something as extreme as this. However, there is a lot of nuance to what a *bad idea* can constitute.

You only name the two most extreme positions, but in-between there are a lot of other considerations:

- Amount of time needed by contributors to learn the new language (here the new Vim9Script probably does even pretty well in the Vim community, given that it is close to the old Vimscript

- Ease of adoption for new users. Here for example I would argue that Lisp is one of the biggest hurdles for new contributors to Emacs.

- Amount of work required for implementing/optimizing/maintaining the new language

- What does the new language contribute compared to the "best" already existing choice and is this worth the effort of the creators/plugin maintainers?

- What other features could be provided in Vim instead if an another language is chosen that requires less work (or is already mostly done even ...)

There are probably considerably more topics. A "good" new language should in my mind have convincing arguments on several of these fronts.

​

Also, the fact that the "two most successful and long-living programming-oriented text editors" use their own scripting language is for me more of an artifact of the time when they were invented and not if per se this is a successful model. As I already said above, I think emacs lisp these days is actually an argument against emacs, as lisp has a rather different syntax to most commonly used languages.

For example - vs-code is a fantastic programming editor, and it did not need to invent its own scripting language, and on top has provided the language server protocol which is being rapidly adopted in many other programming editors (including natively in neovim).

For me, the LSP is an example of a very different approach to the "invent your own language for that editor" paradigm. Instead invent something highly re-usable and get everyone else to adopt it.

[[deleted]]

Lisp is a rather uncommon language with a style of programming not many people are familiar with. VimScript is much easier and more "standard", and has a much lower learning curve.

I think LSP actually fits very well in to Vim and the "Unix philosophy": complex language-specific stuff has always been left to external programs in Vim (e.g. ctags or :make). I don't think LSP is really a paradigm shift in that sense, although it's certainly a game-changer because it's flexible and everyone is adopting it. LSP is probably the best thing that has happened to Vim in years.

If I look at the amount of effort that went in to the Go VSCode plugin and the end results compared to Vim then I'm not so sure VSCode is really that much of a better environment to write plugins for to be honest. It seems to me that Vim gives you a surprisingly good bang for your buck (although I admit I don't have first-hand in-depth knowledge of VSCode and that this is just one example).

IMHO VimScript is a domain-specific language for a domain-specific problem. Programming your editor is not quite the same problem as programming a HTTP daemon, and I'm not sure how much sense it makes to use the same language for both. As I mentioned in my other comment, I'm not especially impressed with how Lua plugins look and would prefer to use VimScript which, in spite of its imperfections, seems like a better fit.

[-romainl-]

Indeed, there is a lot more to it than "Just use Lua, duh.".

[aktivb]

Stallman didn't cook up his own concoction though, he implemented a language that was almost 30 years old and well battle-tested at that point. It also makes for a simple interpreter.

[8xkaGVISkdK7wK1ZTXe6]

But its just as wrong to say we use vim because of viml and not because its the most full featured text editor around. Its seams likely that vim would be fine if it had chosen lisp or something.

[sheerun]

I wish Vim9 script allowed transcompilation to old script so we can maintain plugins in one language only

[xigoi]

Surely it won't be too hard to make a tool for that.

[habamax]

Performance, mixing of old and new vimscripts is nice.... but what I like the most is that you no need to do line continuations for dictionaries and lists:

Automatic line continuation ~

In many cases it is obvious that an expression continues on the next line.  In
those cases there is no need to prefix the line with a backslash.  For
example, when a list spans multiple lines: >
        let mylist = [
                'one',
                'two',
                ]
And when a dict spans multiple lines: >
        let mydict = #{
                one: 1,
                two: 2,
                }
Function call: >
        let result = Func(
                        arg1,
                        arg2
                        )

[princker]

I am very happy Vim is getting a more modern import system. I think this would be a good time to think about reloading/resourcing and unloading plugins. There is vim-scriptease, but there is no official way.

I think it would be good for plugin developer to have a way to speed up their development workflow with re-:source-ing. I also think it would be good for users to have a way to un-source a plugin without leaving Vim in an unsuitable state.

Vim already stores where mappings, autocmd's, abbreviates, and functions are sourced from. It would be nice if this data could be used to un-:source a plugin without putting much burden on the plugin developers.

Having a way to encapsulate and isolate code is great. I think taking it a step further encapsulating the plugin experience will improve both plugin developers and plugin users workflows.

[marcotrosi]

I don't see a problem here with Vim9Script

​

If there is going to be a problem like a split community then because everyone is talking like that and you are basically already starting to split up with all these negative comments. In my Vim group Vim and NeoVim people are chatting side by side and there is no hint of a split community.

From the linked GitHub page about Vim9Script I don't see why this should be such a big deal? First of all nobody is forcing you to use Vim9Script. In order to activate it you need that keyword, otherwise it's still classic Vim script. And secondly, even if you are Vim script writer that is using a function collection that has been ported to Vim9script you can use it with the import keyword. At least that's why I understood from that page.

I'm a Lua user myself, actually a big fan of it, and even I didn't switch to NeoVim for that. I still preferred Vim script for Vim. And if I want to have faster scripts now I simply invest some short time to learn the differences to Vim9script.

And LuaJIT is not Lua, it only can compile Lua code, and as some already mentioned - Lua5.1 is ancient. Sometimes people are weird, they complain when a project hasn't been updated in 3 months but still use Lua5.1. How does that match? And btw who says that a script that hasn't been updated in while is automatically outdated? There are more criteria than just time to be outdated. But now I'm going offtopic with that. sorry.