Dedicated file type for vim9script ?

[skywind3000]

trafficstars

Instructions: Replace the template text and remove irrelevant text (including this line)

When I am creating snippets for vim9, it is hard to tell if the current file is legacy vim or vim9script without parsing it.

the &commentstring for vim9script is still "%s, it is confused for plugins like vim-commentary.

If there is a new filetype vim9 for new extension .vim9, every other plugins can easily tell the script version.

Describe the solution you'd like

• introduce a dedicated file type vim9 for every .vim9 file.
• different &commentstring or something for vim9 type.
• If the file type is vim9, it is unnecessary to include a vim9script line.

If .vim9 is a little bit long, consider .v9 ??

[inkarkat]

the &commentstring for vim9script is still "%s

Well, the ftplugin tries to do auto-detection, but I also wonder whether that's sufficient.

I've already been negatively affected by false # comment highlighting in legacy Vimscript (I frequently confuse the comment character when I'm doing shell scripting in parallel). The syntax script currently indiscriminately allows the Vim 9 comment syntax also in pure legacy Vimscripts. I'd love to have a better separation here.

Of course, a separate filetype would make that much easier; on the other hand, a mix of both syntaxes in a single file (as described by :help vim9-mix would then be harder to implement (syntaxes could use :syn include, but ftplugin-stuff like 'commentstring' is buffer-local).

[brammool]

When I am creating snippets for vim9, it is hard to tell if the current file is legacy vim or vim9script without parsing it.

the &commentstring for vim9script is still "%s, it is confused for plugins like vim-commentary.

If there is a new filetype vim9 for new extension .vim9, every other plugins can easily tell the script version.

Describe the solution you'd like

• introduce a dedicated file type vim9 for every .vim9 file.
• different &commentstring or something for vim9 type.

If .vim9 is a little bit long, consider .v9 ??

I do not think this is a good solution. For example, in a legacy script you can have a :def function, which uses Vim9 script syntax. And inside a Vim9 script you can have a :function with legacy syntax.

'commentstring' is set according to finding "vim9script" at the top of the file. It's hard to do more than that.

Perhaps the syntax highlighting could be improved with a global "vim9" region, which is also used inside a :def function and gets a nested "legacy" region when encountering :function. This is tricky, but it might work.

-- Arthur pulls Pin out. The MONK blesses the grenade as ... ARTHUR: (quietly) One, two, five ... GALAHAD: Three, sir! ARTHUR: Three. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net \
/// \
\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Shane-XB-Qian]

to help vim legacy script stay working, probably not to separate to new v9 ft, besides vim9 script can use (embedded) legacy script as well, then how could it be a v9 ft. something like markdown fs, some langs embedded into ``` scope, but there is not md_foo, md_bar ........ that's Not something like colortheme which perhaps on t_co & term

[dkearns]

Of course, a separate filetype would make that much easier; on the other hand, a mix of both syntaxes in a single file (as described by :help vim9-mix would then be harder to implement (syntaxes could use :syn include, but ftplugin-stuff like 'commentstring' is buffer-local).

I've been using CursorMoved autocommands and searchpair region detection to update the options. It works OK.