[Discussion]: Dropping support for vim

[saccarosium]

I think that having to support vim is holding the plugin back. This could lead us to:

1. instead of using our own home-grown regex system to find links in the page, we could be just hooking into treesitter, opening the door to more high quality support for filetypes, without actually be a filetype plugin (also we could support restructuredText and having better org support).
2. We can use leverage the neovim's lua ecosystem giving us the opportunity to have a more consistent and composable plugin by delegating some of the work we were doing here, to other plugin that would do a much better job of dealing with those issues.
3. have a much more performat and hackable base to create UI on top of the plugin and even having a graph view!

For the transition we could do something like what was done with command-t.

Obviously this is a discussion so I would love to here the reasons why we should keep vim compatability.

[lervag]

I think that having to support vim is holding the plugin back.

Well, at least partly. I do consider it an interesting idea to drop Vim support. I don't use Vim personally. I think wiki.vim is so mature that forking it into wiki.nvim and then archiving wiki.vim is not necessarily bad for the Vim community. wiki.vim would still be available for anyone to use, and of course also to fork. The MIT license means anyone is free to continue a Vim fork, if they want to.

This could lead us to:

1. instead of using our own home-grown regex system to find links in the page, we could be just hooking into treesitter, opening the door to more high quality support for filetypes, without actually be a filetype plugin (also we could support restructuredText and having better org support).

I don't want to throw away the regex system, because it actually works quite well, and it works across filetypes.

I think the first step is to continue what I've already started: make the APIs to find links even more "general". I think this is quite close already, and I'm working (slowly) towards allowing a solution for #147 (multi-line links). A more general interface for detecting and parsing links would then allow additional backends e.g. for Treesitter.

2. We can use leverage the neovim's lua ecosystem giving us the opportunity to have a more consistent and composable plugin by delegating some of the work we were doing here, to other plugin that would do a much better job of dealing with those issues.

If we do go forwards with a neovim-specific fork, then I think it would be useful to consider adopting some new principles/ideas. One of those would probably be to allow dependencies. For instance, it may well be possible that e.g. plenary.nvim provides some of the features I've manually implemented. Also, we might want to adopt nui.nvim for some UI elements, and perhaps fork out the blocking UI stuff as a new library.

3. have a much more performat and hackable base to create UI on top of the plugin and even having a graph view!

A better graph view would be cool :)

For the transition we could do something like what was done with command-t.

Feel free to outline the ideas from the video (TLDV :p).

Obviously this is a discussion so I would love to here the reasons why we should keep vim compatability.

I've been keeping Vim compatibility so far because I didn't have a good reason not to. However, the neovim APIs are really getting good, the community is getting stronger, and I am starting to feel that there are two very good reasons to consider this:

1. Keeping Vim compatibility and staying in Vimscript is probably holding contributors back. By going full Neovim and allowing more of the code to be written in Lua, I think it would be easier to get more people on board to help with further development and maintenance.

2. It is hard to adopt the new Neovim APIs (even in Vimscript) because of Vim compatibility. Dropping Vim support would allow me/us to leverage the new APIs in full.

---

So: I'm actually quite positive towards this idea. Open questions:

1. What is the best approach for actually doing the fork? I mean, do we make a final release of wiki.vim with an updated README file and then archive it, and then fork wiki.vim into wiki.nvim?

2. Which new "principles" or "requirements" should we adopt? Allowing some dependencies to e.g. plenary.nvim or similar seems useful. Perhaps stating that we assume the user is using the latest version of Neovim is also useful? However, that would require everyone to stay bleeding edge. If we specify a neovim version; perhaps we can update neovim version requirements on each release?

[lervag]

I've invited the Vim and neovim communities on Reddit to join this discussion:
https://www.reddit.com/r/neovim/comments/15axuas/discussion_considering_to_to_vim_support_in/

[lervag]

For the transition we could do something like what was done with command-t.

OK, I watched the video now. I don't think I want to follow the same idea for transition here, because I don't intend to rewrite everything in Lua as part of the transition itself. That is:

1. The Vimscript code is (IMHO) quite good. We don't need to rewrite it, unless it is particularly slow.
2. Many (if not most) of the useful neovim APIs are also available for Vimscript. Thus, one of the first things I would do after dropping Vim support would be to utilize these APIs everywhere. It would allow several simplifications of the code!
3. If I drop Vim support, then I want that to lead to less and more simple code.

[saccarosium]

don't want to throw away the regex system, because it actually works quite well, and it works across filetypes.

I think the first step is to continue what I've already started: make the APIs to find links even more "general". I think this is quite close already, and I'm working (slowly) towards allowing a solution for #147 (multi-line links). A more general interface for detecting and parsing links would then allow additional backends e.g. for Treesitter.

Understandable.

What is the best approach for actually doing the fork? I mean, do we make a final release of wiki.vim with an updated README file and then archive it, and then fork wiki.vim into wiki.nvim?

You could also make the final release with vim support and mention it in the README, and then simply continuing developing on this repo. I don't really see a reason to fork the project, unless you want to clearly separate the two plugins.

Which new "principles" or "requirements" should we adopt? Allowing some dependencies to e.g. plenary.nvim or similar seems useful. Perhaps stating that we assume the user is using the latest version of Neovim is also useful? However, that would require everyone to stay bleeding edge. If we specify a neovim version; perhaps we can update neovim version requirements on each release?

Well, I think that having a "minimal" core and than extend it with plugins is the way to go (I think of nvim-cmp and basically all neovim features). Perhaps the graph view could be a separate plugin (to make that thing to work good would require some effort and dependencies.

If we go with a minimal core we should think of what exactly we want and don't want in the main plugin, and than separate the rest in separate plugin.

For the "core" plugin I wouldn't go with more than plenary.nvim as a dependency.

As for the requirements... Neovim moves really fast, especially now. So I think that targeting either: Debian stable version (now is 0.7) or the prior major version (would mean now 0.8).

[clason]

For the "core" plugin I wouldn't go with more than plenary.nvim as a dependency.

I'd strongly advise against using plenary.nvim as a dependancy these days. It was very valuable as an incubator in the early days (when Neovim's API was much more limited, especially from Lua), but has not kept up-to-date (understandably, as it's a massive and complicated codebase with only part-time maintainers). These days, Neovim's "standard library" should be sufficient, and gaps should be filled (if pointed out with a reasonable use case).

I'd make an exception for an ui plugin, where nui.nvim seems indeed like a good choice (it's got the Folke Seal of Approval :D); bonus points if it's optional (meaning you get a basic UI if it's not installed; there's vim.ui for some simple components like input and select that plugins can extend).

Neovim moves really fast, especially now. So I think that targeting either: Debian stable version (now is 0.7) or the prior major version (would mean now 0.8).

That is indeed an issue -- but so do Neovim users.

The official stance of Neovim is that we only support the latest release as well as the latest(!) commit on HEAD; that may be too aggressive for this plugin. But I would definitely not recommend looking at distro versions (and certainly not Debian, which will hopefully update one day, but no promises) to decide what to support. Rather, I'd look for features that make your life easier and require a version based on that; evaluate this every time a new minor version comes out (are new APIs worth dropping support for older versions?), possibly after the first patch (which usually comes relatively soon after a big release). Right now, it would be reasonable to require 0.9, but it doesn't make much sense forcing yourself to support anything older than 0.8.

[lervag]

@saccarosium

What is the best approach for actually doing the fork? I mean, do we make a final release of wiki.vim with an updated README file and then archive it, and then fork wiki.vim into wiki.nvim?

You could also make the final release with vim support and mention it in the README, and then simply continuing developing on this repo. I don't really see a reason to fork the project, unless you want to clearly separate the two plugins.

Yes, this seems like a good idea. It was also suggested in one of the Reddit threads. I think it would make sense to specify this as a release tag where e.g. release v0.9 is the final release with support for Vim. (If I choose to go this direction.)

Which new "principles" or "requirements" should we adopt? Allowing some dependencies to e.g. plenary.nvim or similar seems useful. Perhaps stating that we assume the user is using the latest version of Neovim is also useful? However, that would require everyone to stay bleeding edge. If we specify a neovim version; perhaps we can update neovim version requirements on each release?

Well, I think that having a "minimal" core and than extend it with plugins is the way to go (I think of nvim-cmp and basically all neovim features). Perhaps the graph view could be a separate plugin (to make that thing to work good would require some effort and dependencies.

I'm not sure I agree with that. Maintaining multiple small plugins would be harder, not simpler for me. And I don't really see any real benefit from this. In my opinion, the important thing is to keep things modular, well structured, and flexible.

If we go with a minimal core we should think of what exactly we want and don't want in the main plugin

Let's consider this regardless. Perhaps it will make sense to pull some parts into a separate plugin/extension, but even if it does not, it can be useful to recognize parts that should be contained in separate modules. I believe this is already quite well structured, but I may be missing things!

As for the requirements... Neovim moves really fast, especially now. So I think that targeting either: Debian stable version (now is 0.7) or the prior major version (would mean now 0.8).

Yes, Neovim moves fast; I would really like to not stay too far behind, though. It is one of my motivations for doing this shift in the first place, so if I were to stick to old neovim versions, I feel the motivation is not as strong. So, in this, I am more inclined to agree with @clason.

@clason

For the "core" plugin I wouldn't go with more than plenary.nvim as a dependency.

I'd strongly advise against using plenary.nvim as a dependancy these days. It was very valuable as an incubator in the early days (when Neovim's API was much more limited, especially from Lua), but has not kept up-to-date (understandably, as it's a massive and complicated codebase with only part-time maintainers). These days, Neovim's "standard library" should be sufficient, and gaps should be filled (if pointed out with a reasonable use case).

Thanks! That's a useful advice!

I'd make an exception for an ui plugin, where nui.nvim seems indeed like a good choice (it's got the Folke Seal of Approval :D); bonus points if it's optional (meaning you get a basic UI if it's not installed; there's vim.ui for some simple components like input and select that plugins can extend).

Also useful. And I agree. Notice, though, that vim.ui.* rely on the IoC concepts and can not be used in the same way that e.g. the standard Vimscript input() or inputlist() functions are used.

And I also think we need basic UI with an optional possibility of relying on additional ones from e.g. nui.nvim.

Neovim moves really fast, especially now. So I think that targeting either: Debian stable version (now is 0.7) or the prior major version (would mean now 0.8).

That is indeed an issue -- but so do Neovim users.

The official stance of Neovim is that we only support the latest release as well as the latest(!) commit on HEAD; that may be too aggressive for this plugin. But I would definitely not recommend looking at distro versions (and certainly not Debian, which will hopefully update one day, but no promises) to decide what to support. Rather, I'd look for features that make your life easier and require a version based on that; evaluate this every time a new minor version comes out (are new APIs worth dropping support for older versions?), possibly after the first patch (which usually comes relatively soon after a big release). Right now, it would be reasonable to require 0.9, but it doesn't make much sense forcing yourself to support anything older than 0.8.

Thanks, this is very similar to how I'm thinking. It would actually be quite nice to allow for a very aggressive approach here. But I may consider being somewhat conservative, but at least with a strategy of moving with the times. E.g., if I restrict myself to 0.9 now, I should already plan for moving to version 0.10 when it arrives.

One idea could be to start relatively conservative in the first iteration; e.g. with 0.8. Then make a release when I reach a stable level. Then I can adapt to version 0.9 and make a new release - and I could specify in the README that those who use older neovim can stay on release X, and so on.

[clason]

I think a basic policy of "move baseline to the latest 0.x release if it allows simplifying/improving the plugin, but only after 0.x.1 is released" is a very sound (and relatively conservative, in Neovimland) strategy.

Also useful. And I agree. Notice, though, that vim.ui.* rely on the IoC concepts and can not be used in the same way that e.g. the standard Vimscript input() or inputlist() functions are used.

Doesn't mean they have to stay that way, given a compelling argument ;)

[lervag]

I think I will procede as follows:

• The next release will be the last release with the current version requirements.
• I will use the release mechanism as a method of changing Vim/neovim version requirements from now on, and I will use it more actively.
• After the next release, I will bump the requirements to Vim version 9 and neovim v0.9. I will then iterate through the code and allow myself to simplify and improve things by utilizing the new/updated functionality.
• I will also use this time to consider what I want to do with regards to future Vim compatilibity.

I may decide to keep Vim compatibility. If so, it will be because I conclude that I can leverage Neovim features properly while keeping Vim compatibility. If I don't see a good way of doing both, then I believe I may drop Vim compatilibility.

[lervag]

I think a basic policy of "move baseline to the latest 0.x release if it allows simplifying/improving the plugin, but only after 0.x.1 is released" is a very sound (and relatively conservative, in Neovimland) strategy.

Thanks. I think I want to avoid being too conservative, because I want to be able to utilize the new and improved stuff. :)

But I will try and be clear about the requirements as explained in my previous comment.

Also useful. And I agree. Notice, though, that vim.ui.* rely on the IoC concepts and can not be used in the same way that e.g. the standard Vimscript input() or inputlist() functions are used.

Doesn't mean they have to stay that way, given a compelling argument ;)

I looked into discussions on this topic, and it seemed to me that neovim people did not really want to consider this. It was claimed that IoC was necessary to allow non-blocking behaviour, which I guess is true.

In all discussions I've seen, people just say that, if I can't use vim.ui.input because of the specified reason, then I should just use input().

I would personally be very happy to see modern versions of the input(), inputlist() and confirm() functions that allowed better UIs restricted to the "old"/"legacy" blocking way. Something akin to vim.ui.*. But I'm not sure how to implement these things myself and contribute to neovim core; and I'm also not sure if it is something people want.

[clason]

Do you have a link to that discussion? Maybe all that's missing is a reasoned argument (and detailed design proposal) for the new methods. We get frequent requests which boil down to "we need Lua API because ewww vimscript!", even though vim.fn is not vimscript, so there tends to be some initial pushback. Now that we have vim.ui, we should make it as good as possible ;)

[lervag]

Do you have a link to that discussion? Maybe all that's missing is a reasoned argument (and detailed design proposal) for the new methods. We get frequent requests which boil down to "we need Lua API because ewww vimscript!", even though vim.fn is not vimscript, so there tends to be some initial pushback. Now that we have vim.ui, we should make it as good as possible ;)

I've tried to find it, but either my memory is not precise or I may be remembering discussions on Reddit instead of the neovim issue tracker.

I opened an issue about this now with a proposal for select - let's start there: neovim/neovim#24632.

---

Now, I'll close this issue as resolved by our discussion. It has been useful to me and I will act on it according to me previous comment.

[trev-dev]

Just throwing my late feedback into the hat! If vim support is dropped, it would be unfortunate! Since the focus of upstream will most likely shift to Lua, I would not mind seeing the "legacy" wiki.vim migrated to vim9script.

The more amazing vim9 plugins the better.

[lervag]

Just throwing my late feedback into the hat! If vim support is dropped, it would be unfortunate!

Yes, I can understand that Vim (not neovim) users will feel that way. I do have some sadness that things are going into the direction of Vim and neovim not being properly compatible.

In any case, I will most likely not drop Vim support very soon.

Since the focus of upstream will most likely shift to Lua, I would not mind seeing the "legacy" wiki.vim migrated to vim9script.

If someone wants to fork wiki.vim and migrate it to vim9script I would be more than happy to add a link to that project. I don't know if I could be of any help, but the effort would definitely have my blessings.