No vim9script in syntax, ftdetect files #10968
Comments
Nowadays, I would prefer to write ftplugins using vim9script, to be honest (Folding, indent functions + helper script functions). I am not sure, considering how many different people contributes to ftplugins, there is a way to limit what they do. |
|
[my reply went to the maillist but didn't show up on github, sorry if you see it twice] This is a preference of the script maintainer. Using Vim9 script is not I do not want to impose restrictions on what script version the runtime You might want to reconsider not supporting Vim9 scripts. Without it |
Merging vim9script is out of scope for Neovim, but we're considering some sort of conversion. |
|
While Vim9 has the drawback of not being supported by Neovim, it's a nice improvement for Vim: faster, stronger type safety, cleaner syntax. And Vim9 can nicely coorperate with the old Vim script, making the transition smooth. IMO, what Neovim supports or not should not hinder the development of Vim in general. Neovim developers chose to clone Vim, so Neovim therefore has to accept the price of that decision. Vim is the original implementation with decades history before Neovim. I can imagine that it's not only Vim9 which causes pain for Neovim, it's also maybe the fact that code and features diverges more and more over time, so merging all Vim bug fixes or features is likely to become harder and harder. There are of course pros & cons of cloning, as Neovim can do what it wants and it has shown to be quite popular and innovative so far, experimenting with features as a result, which have sometimes been put into Vim later when it makes sense (e.g. terminal, async, floating windows, ...sometimes differently). Of course, if something is reasonably simple without major to drawbacks to implement in Vim in a compatible way with Neovim then why not. But it's fair to say that this is not the case here. Still for Vim & Neovim users, it's annoying that plugins can become more and more VIm specific or Neovim specific. It's sometimes because of new Vim features such as Vim9 and sometimes (or more often I suspect) because of new Neovim features such Lua API. So we are bound to see plugin which are for Vim only or for Neovim only. I hope there will some convergence even if takes time. Ideally, it would mean for Neovim to support Vim9 script. I thought there were ideas about converting Vim9 to Lua maybe, but I admit I do not follow closely what Neovim is doing. |
|
Luckily, plugin authors have figured out how to reach the maximal audience of both Vim and Neovim (EDIT: and, let's not forget, Vim 8 and Vim 7) users: Write their plugin in Vimscript (with a judicious use of What Vim itself does is of course up to the project; if the current symbiotic relationship is deemed to be of no value, then so be it, and runtime file improvements can no longer be sent here first. |
that had been happened some years, obvious case is but luckily, official vim was going to support those sooner or later.. |
Well, not quite. I made the case for that: for ftplugins and syntax files, there are no major drawbacks for Vim to limiting them to Vimscript, only superficial/political drawbacks. |
Superficial/political my eye. |
|
@clason wrote:
This is possible, but it's not perfect:
|
|
Complex plugins frequently require independent development and testing to support vim and neovim, irrespective of implementation language; the feature and API divergence (as mentioned by Dominique.. popups, text properties, channels, etc.) require plugin authors to have dual implementations or wrappers for those feature sets (or choose to only support one), anyway. Admittedly, this may form only a small abstraction layer, and choosing to implement an entire plugin in a language/using an API that's not portable necessarily implies it can only work in one of the runtimes. But that's a decision for the plugin author to determine what they want to support. But that is, with respect, aside from the point that Justin is making, which is to request that maintainers of runtime files restrict their usage in certain ways in order to share them across implementations (vim, neovim). And as Bram said, that's a decision for the individual maintainer, whether it be superficial and political or not. One might be forgiven for arguing that the decision to not merge vim9script patches to neovim was "superficial/political", but one would probably accept that is grossly understating the nuance. Nonetheless, it would appear somewhat incongruous to reject runtime files from vim which were written in vim9script. FWIW I think there's a good "for the benefit of all" argument for many runtime files that are executed only once to be written in (or at least, remain written in) legacy vimscript, bu I'm just speculating, I have no skin in the game for runtime files. |
|
(This is getting off-topic for the actual issue, but I still think this is a useful discussion to have, and here it has the biggest chance -- albeit no guarantee -- to stay fact-based and civil.)
It's not a matter of doubt; you can easily check this in practice. With the exception of a handful of plugins from some core Vim contributors, I am aware of no Vimscript plugin author that does not make at least some effort to support both Vim (including older versions!) and Neovim. (@puremourning's plugin is definitely on the lower end of this support spectrum, but then vimspector is definitely one of the most complex, interface-heavy, Vim plugins I am aware of, so that is perfectly understandable.) So the assumption that plugin authors are champing at the bit to rewrite everything in Vim9script and leave Neovim in the dust is a tad optimistic. We may see a big migration in the future (when Vim9 is as ubiquitous as Vim7 is now), but I don't see any indication of it at the moment. (Again, this is about external plugins; Vim can do with its bundled runtime as it sees fit. Although I do want to point out that a sizable portion of these files come from external repos that serve as standalone filetype plugins, for which the above considerations very much apply.) |
This is not only off-topic, but patently untrue. |
|
I apologize, I did not mean to turn this into a personal remark; the formulation was unfortunate and unwarranted. But I stand by my point that vimspector is one of the very few Vimscript plugins I am aware of that does not work equally well on Neovim and Vim (for understandable technical reasons, not deliberate lack of effort), even though you do take pains to support Neovim as much as possible -- which was my actual point. |
No worries, I think i understood your intended meaning - I just don't agree with it :)
I'm not sure why vimspector is part of the discussion, but for the record, so far as I know vimspector only lacks certain features in neovim because they are, or were, not available. (perhaps with the exception of the neovim WinBar implementation which is for some reason different from vim's and I haven't had the impetus to implement that yet). Otherwise, I believe I have more code that is specific to neovim than code specific to vim: I belive that prompt buffers work in both now, and have recently added running neovim tests in CI. So I know what decisions and sacrifices are required to suppport a complex plugin on both environments. It's true to say that in YouCompleteMe many features aren't implemented for neovim; this is largely due to the fact that there are many excellent alternatives that work great in neovim, and I have only so much time I can spend on OSS. Implementing (or not implementing) the same stuff multiple times for little benefit or few users is a 'business' decision that I make to manage my limited free time.. I'm sure other plugin maintainers have simlar thought processes. It's also true to say that many of the neovim-specific patches (such as the balloon popup and CI) have been from community contributions, rather than entirely done by me, though the initial port to neovim was a lot of work. All of that is to say that OSS plugin authors will spend time on what is valuable and interesting to them and their user base, and it's (as I said above) a decision we already have to make, largely independently of, or at least as well as, implementation language. |
|
I'm not sure why vimspector is part of the discussion
perhaps due to i mentioned `lsp` and `dap` at above comment.. :-)
following words perhaps `off topic` & just IMO :
- i am not sure how many users using `dap` due to what's feature or reason, but i guess `java` was the much one,
but so far `vimspector` should be most best one in official vim, but unfortunately seems still not as easy as like `vsc`,
there were some alternatives (pls search or guess what's these), but unfortunately seems specifically to 'neovim' only...
…--
shane.xb.qian
|
|
I support rewriting runtime files in vim9script. I believe it is a good thing because even if most of us are not familiar with vim9script, Like a much faster file type detection, why not? On the other hand, It'll get vim9script itself widely tested (by thousands of vim9 users). |
|
Justin M. Keyes wrote:
## Problem
Files such as
https://github.com/vim/vim/blob/master/runtime/syntax/context.vim were
converted to Vim9script without any apparent technical reason. This
means Neovim can't import such runtime files from Vim.
Neovim doesn't plan to merge Vim9script support, but we would like to
continue using Vim's syntax files.
## Proposal
Neovim project doesn't expect Vim to limit its use of vim9script for
performance-sensitive code (such as plugins), or where there is a
maintainability gain. But for "declarative" files like syntax
definitions and ftdetect, is there any such benefit?
If Vim sticks to legacy Vimscript for syntax and ftdetect files,
Neovim can continue to send patches / requests upstream to Vim.
Otherwise we'll have to fork those files to Lua and this will diverge
the projects further.
This is a preference of the script maintainer. Using Vim9 script is not
only for performance, it also is closer to popular languages and has
better detection for errors/warnings, line continuation without
backslashes, etc. etc. Vim9 script was added because it is better in
many ways, we can expect it to be used.
I do not want to impose restrictions on what script version the runtime
files are written in.
You might want to reconsider not supporting Vim9 scripts. Without it
many plugins will not work with NeoVim. Or perhaps you can make a tool
to convert the script to whatever you like (likely much more work).
…--
Veni, Vidi, VW -- I came, I saw, I drove around in a little car.
/// 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 ///
|
Problem
Files such as https://github.com/vim/vim/blob/master/runtime/syntax/context.vim were converted to Vim9script without any apparent technical reason. This means Neovim can't import such runtime files from Vim.
Neovim doesn't plan to merge Vim9script support, but we would like to continue using Vim's syntax files.
Proposal
Neovim project doesn't expect Vim to limit its use of vim9script for performance-sensitive code (such as plugins), or where there is a maintainability gain. But for "declarative" files like syntax definitions and ftplugins, is there any such benefit?
If Vim sticks to legacy Vimscript for syntax and ftplugins, Neovim can continue to send patches / requests upstream to Vim. Otherwise we'll have to fork those files to Lua and this will diverge the projects further.
The text was updated successfully, but these errors were encountered: