Mirror of the Vim source from https://github.com/vim/vim
What is Vim9?
This is an experimental side of Vim. It explores ways of making Vim script faster and better.
WARNING: The Vim9 script features are in the early stages of development, anything can break!
1. FASTER VIM SCRIPT
The third item on the poll results of 2018, after popup windows and text properties, is faster Vim script. So how do we do that?
I have been throwing some ideas around, and soon came to the conclusion that the current way functions are called and executed, with dictionaries for the arguments and local variables, is never going to be very fast. We're lucky if we can make it twice as fast. The overhead of a function call and executing every line is just too high.
So what then? We can only make something fast by having a new way of defining a function, with similar but different properties of the old way: * Arguments are only available by name, not through the a: dictionary or the a:000 list. * Local variables are not available in an l: dictionary. * A few more things that slow us down, such as exception handling details.
I Implemented a "proof of concept" and measured the time to run a simple for loop with an addition (Justin used this example in his presentation, full code is below):
That looks very promising! It's just one example, but it shows how much we can gain, and also that Vim script can be faster than builtin interfaces.
In practice the script would not do something useless as counting but change the text. For example, re-indent all the lines:
The differences are smaller, but Vim 9 script is clearly the fastest.
How does Vim9 script work? The function is first compiled into a sequence of instructions. Each instruction has one or two parameters and a stack is used to store intermediate results. Local variables are also on the stack, space is reserved during compilation. This is a fairly normal way of compilation into an intermediate format, specialized for Vim, e.g. each stack item is a typeval_T. And one of the instructions is "execute Ex command", for commands that are not compiled.
2. PHASING OUT INTERFACES
Attempts have been made to implement functionality with built-in script languages such as Python, Perl, Lua, Tcl and Ruby. This never gained much foothold, for various reasons.
Instead of using script language support in Vim: * Encourage implementing external tools in any language and communicate with them. The job and channel support already makes this possible. Really any language can be used, also Java and Go, which are not available built-in. * Phase out the built-in language interfaces, make maintenance a bit easier and executables easier to build. They will be kept for backwards compatibility, no new features. * Improve the Vim script language, it is used to communicate with the external tool and implements the Vim side of the interface. Also, it can be used when an external tool is undesired.
All together this creates a clear situation: Vim with the +eval feature will be sufficient for most plugins, while some plugins require installing a tool that can be written in any language. No confusion about having Vim but the plugin not working because some specific language is missing. This is a good long term goal.
Rationale: Why is it better to run a tool separately from Vim than using a built-in interface and interpreter? Take for example something that is written in Python: * The built-in interface uses the embedded python interpreter. This is less well maintained than the python command. Building Vim with it requires installing developer packages. If loaded dynamically there can be a version mismatch. * When running the tool externally the standard python command can be used, which is quite often available by default or can be easily installed. * The built-in interface has an API that is unique for Vim with Python. This is an extra API to learn. * A .py file can be compiled into a .pyc file and execute much faster. * Inside Vim multi-threading can cause problems, since the Vim core is single threaded. In an external tool there are no such problems. * The Vim part is written in .vim files, the Python part is in .py files, this is nicely separated. * Disadvantage: An interface needs to be made between Vim and Python. JSON is available for this, and it's fairly easy to use. But it still requires implementing asynchronous communication.
3. BETTER VIM SCRIPT
To make Vim faster a new way of defining a function needs to be added. While we are doing that, since the lines in this function won't be fully backwards compatible anyway, we can also make Vim script easier to use. In other words: "less weird". Making it work more like modern programming languages will help. No surprises.
A good example is how in a function the arguments are prefixed with "a:". No other language I know does that, so let's drop it.
Taking this one step further is also dropping "s:" for script-local variables; everything at the script level is script-local by default. Since this is not backwards compatible it requires a new script style: Vim9 script!
between files. Vim currently uses the
We can use the
And in another script import the function:
These are ideas, this will take time to design, discuss and implement. Eventually this will lead to Vim 9!
Code for sum time measurements
Vim was build with -O2.
Code for indent time measurements