Convert remaining core runtime support files to Vim9 script

[dkearns]

This is just some grunt work I committed to some time ago...

It's probably not appropriate for 9.1.

[codecov]

Codecov Report

Merging #13039 (9f02a2f) into master (d2a08ba) will increase coverage by 0.65%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #13039      +/-   ##
==========================================
+ Coverage   81.43%   82.08%   +0.65%     
==========================================
  Files         160      160              
  Lines      194844   194945     +101     
  Branches    43727    43753      +26     
==========================================
+ Hits       158666   160017    +1351     
+ Misses      23422    22061    -1361     
- Partials    12756    12867     +111     

Flag	Coverage Δ
huge-clang-Array	82.70% <ø> (+<0.01%)	⬆️
linux	82.70% <ø> (+<0.01%)	⬆️
mingw-x64-HUGE	76.62% <ø> (-0.01%)	⬇️
mingw-x86-HUGE	77.13% <ø> (?)
windows	78.22% <ø> (+1.59%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 58 files with indirect coverage changes

[chdiza]

Good God, why? Why make some of these core files hard to read unless one knows vim9script? Why screw up git-blame? To save a billionth of a second? And for the files where the only thing changed is the comment character: why? There's not even the negligible benefit to speed there.

Please, leave the runtime files alone. Vim9script is for people with mega-fancy plugins. It should not be polluting runtime.

[Shane-XB-Qian]

import autoload dist/script.vim

[Shane-XB-Qian]

noclear? seems you're using g: var

[Shane-XB-Qian]

noclear? seems you're using g: var

[dkearns]

Good God, why?

Funnily enough, and since you ask in such a melodramatic manner, because god himself asked me to and who are you or I to question the word of god?

Why make some of these core files hard to read unless one knows vim9script?

You must be a fan of line continuation and command separator characters. Each to their own but I'm going to call bullshit on this question.

Why screw up git-blame?

I've had no trouble tracking the history of other converted files when the need arose. The obsession with prioritising the output of a VCS tool over the actual code is asinine.

To save a billionth of a second?

No, to normalise on the latest version of the language which also brings other benefits besides performance improvements.

And for the files where the only thing changed is the comment character: why? There's not even the negligible benefit to speed there.

Now a change in comment characters is too much for you? Companion runtime files using different versions of the language so as not to change the comment character seems totally reasonable.

Please, leave the runtime files alone.

We're not torturing kittens here.

Vim9script is for people with mega-fancy plugins.

According to who? Certainly not the author of the language or program. It's not referred to as "legacy script" for nothing.

It should not be polluting runtime.

It's polluting the purity of the runtime now? This pathological disdain for Vim9 script is one of the strangest things I've ever seen.

You survived the horrors of having runtime/autoload/dist/{script,ft}.vim and others converted eighteen months ago. You survived the winter of our discontent after just the comments and a variable prefix were changed when converting runtime/ftplugof.vim. You will survive this too.

Just be thankful you're, presumably, not a NeoVim user. They rewrote all the filetype detection code in Lua! Won't anyone think of the git-blame output?

P.S. Converting optwin.vim actually found a couple of 'bugs'. Damn those static types - you can't live with them, you can't live without them.

[dkearns]

Thanks @Shane-XB-Qian - will update when I'm next working on it.

[clason]

Just be thankful you're, presumably, not a NeoVim user. They rewrote all the filetype detection code in Lua!

Yes, and for a very good reason. We did not just convert from one language to another but rewrote the whole shindig from scratch to avoid creating a thousand autocommands, for significant performance improvements. You might wish to look into doing the same (in vim9script, of course).

[chrisbra]

it's not only about performance. writing legacy vimscript can be rather messy and has several pitfalls (see the various restrictions introduce by :scriptversion) + plus some rather obscure vim commands/options are not directly allowed (see :h gdefault).

For that reason in addition to the explicit typing rules will give us several benfefits: easier readable scripts + preventing ambigious situtations (which may lead to subtle and hard to find bugs) and those are therefore in my opinion valid reasons to rewrite existing scripts using Vim9.

BTW, I don't believe that vim9 script is harder to read than existing vimscript. I think if you understand vimscript, you will be capable of reading vim9 script as well.

However, I am a bit worried about Neovim compatibility. Not sure if they would be affected by this or if they are already using their own lua implementation for those scripts. If yes, that would be a reason not do convert those scripts. If not, I don't see a reason not to do so (considering that someone is willing to do the work, which apparently people are ;) )

[clason]

However, I am a bit worried about Neovim compatibility.

That is much appreciated :)

Not sure if they would be affected by this or if they are already using their own lua implementation for those scripts

We would definitely be affected, but not hugely so -- we already have diverged for the whole filetype.vim family (see above; partly triggered by vim9 rewrites), and the remaining files are small and effectively frozen. (That's how we deal with such files: effectively freeze them at the point before the rewrite, and manually backport changes if they seem worth it. So it does add a modicum of friction for us.)

The context support files were a much bigger issue...

[dkearns]

However, I am a bit worried about Neovim compatibility.

That is much appreciated :)

I spoke to Bram, at some length, about this prior to the Vim 9 release. I offered to convert everything (including my user maintained files) to give Vim9 script a flying start on release but we agreed not to do that and to not heavily advocate for conversions in order that you could work out a solution at your end.

I was following TJ's compiler that seemed to be making good progress; is that not usable yet? I don't follow closely, but it appears you're not including some of the more recent Vim9-script runtime file additions like ftplugin/gdscript.vim.

I don't know what the solution is but I have a lot of stuff batched up in my repo that's been waiting for a green light. I wouldn't write anything in legacy script again if given the choice and it makes absolutely no sense to have performance intensive indent scripts, for example, in legacy script.

I'm concerned that Vim9 script is in danger of becoming a white elephant if it doesn't see increased adoption in the near future which would, I think, be a great shame.

[clason]

I was following TJ's compiler that seemed to be making good progress; is that not usable yet?

It's usable, but not to the point where it can convert arbitrary vim9script (which is still a bit of a moving target) yet. We've tested it with cfilter and ccomplete so far.

I don't follow closely, but it appears you're not including some of the more recent Vim9-script runtime file additions like ftplugin/gdscript.vim.

That is correct. We do not port vim9script filetype plugins (yet); any rewrite means the plugin remains frozen at the pre-rewrite (for now). We also do not see much point in rewriting these in Lua, as Vimscript Classic is a perfectly fine DSL for that purpose.

I don't know what the solution is but I have a lot of stuff batched up in my repo that's been waiting for a green light. I wouldn't write anything in legacy script again if given the choice and it makes absolutely no sense to have performance intensive indent scripts, for example, in legacy script.

Thank you for the heads-up. If a concerted push to rewrite the Vim runtime in Vim9script is coming, we will need to consider our options sooner rather than later. (It would be a shame, but freezing files is a solution, especially for languages with a serviceable tree-sitter parser.)

[clason]

(Just to be clear: I am not campaigning for you to hold off on anything here; I'm just providing context that was asked for and showing my -- genuine -- appreciation for the consideration, which is not a given.)