echasnovski
Dual distribution
Consider the idea of having dual distribution: bundled (current) and separate (each module in own repository). As there seems to be a visible demand for using some modules, but only as separate "conventional" plugin.
Things to think about:
- How it will affect "popularity" and "marketing" of 'mini.nvim' itself.
- Design a workflow which should have little overhead of current approach of just working on this plugin. The "bundled" version should still have central role and evolve as before. Current ideas:
- Decouple common files: help and readmes.
- Reword documentation to work in both distribution versions.
- Write a script that generates git patches from history. Run it periodically and apply patches (maybe even as Github Action?).
To others: if you happen to have a strong opinion about this, please leave some reaction to this comment.
I think mini.nvim definitely undersells itself! There are so many features with decent completeness bundled together. But it doesn't gain too much popularity maybe because the plugin's name?
I would think separate all of them in separately repo would be a good idea, and keep mini.nvim be a bundle of all of them.
Another thing about the doc: I never use vim's doc for searching doc other than the builtin functionalities. I would always go to the plugin's github repo. I also thinks that the format of vim doc is horrible: if we don't want to view the doc within nvim, we have many better other way to exhibit the documentation,
Thanks for your thoughts!
I think mini.nvim definitely undersells itself! There are so many features with decent completeness bundled together. But it doesn't gain too much popularity maybe because the plugin's name?
I would think separate all of them in separately repo would be a good idea, and keep mini.nvim be a bundle of all of them.
This might true. However, it is what it is. Renaming it is a huge breaking change at this point (not only with github repo link and require() calls, but also with all exported _G.Mini* functionality). I don't like that.
My current hope is to create 20 separate mini.* repos which will be semi-automatically updated through git patches and find a way to "rebrand" mini part to something more broad. I might have preferred entirely different names for them, but it would require at least twice the work to maintain both distribution ways.
Another thing about the doc: I never use vim's doc for searching doc other than the builtin functionalities. I would always go to the plugin's github repo. I also thinks that the format of vim doc is horrible: if we don't want to view the doc within nvim, we have many better other way to exhibit the documentation,
Well, I always prefer using :help over anything else. It is so convenient with Telescope help_tags. Format could be better, true, but I really wish more "modern" plugins utilize vim help (that was the reason I wrote 'mini.doc').
It would be cool to have some plugins in separate repositories to lazily load some of them.
For example, now I'm loading some of the plugins (pairs, cursorword) on the BufReadPost event, but I can't specify another events for other plugins (starter, sessions).
It would be cool to have some plugins in separate repositories to lazily load some of them.
For example, now I'm loading some of the plugins (pairs, cursorword) on the BufReadPost event, but I can't specify another events for other plugins (starter, sessions).
It certainly is possible to lazy-load modules separately. Mainly because having 'mini.nvim' in runtimepath literally doesn't do anything more. In order to do something, there should be explicit require() call.
I assume, you have set up lazy loading via 'packer.nvim', which does so per-plugin. You can have it not lazy load (or load on VimEnter) and instead have config that defines lazy loading of modules explicitly via autocommands and ++once directive. Not super convenient, I agree, but possible.
I don't use 'packer.nvim' and implemented lazy loading by simply deferring until after everything in startup is done. This is enough for boosting startup time and useful because first screen is 'mini.starter' (it eats some milliseconds, enough for other plugins to load). Here is the reference.
All that said, I currently decided to make dual distribution after this git repo gets 1000 stars. Almost everything is ready, just needs some repetitive work.