It seems to me there is a clear win in having the vim plugin live in a separate repo as this will make integration with vim much easier and this matches how other vim plugins are deployed.
Personally, I think the solution proposed by this RFC is the best option. However, I would recommend that instead we implement something like what is done for mlir-vscode, as this would give us a standalone repo with the plugins while avoiding some of the downsides of removing the code from the monorepo.
This proposal makes sense to me, as a separate repo just appears to be an idiomatic way. I asked #neovim to hopefully get some feedback.
I don’t mind new LLVM IR keywords do not receive immediate support from a dedicated vim repo.
I believe many people don’t use new keywords and for those who use, un-highlighted keywords should not be a big problem.
The discoverability problem for a separate repo isn’t that different from figuring out that llvm/utils/vim/ in the monorepo is the official directory.
Note: sparse checkouts make cloning slightly faster but not that much and the steps are involved.
git init
git remote add origin https://github.com/llvm/llvm-project.git
git config core.sparseCheckout true
echo llvm/utils/vim >> .git/info/sparse-checkout
git pull origin main # slow
ls # just llvm/
du -sh .git # 2.4G
git clone --filter=blob:none --sparse https://github.com/llvm/llvm-project.git # still slow
du -sh llvm-project # 576M
cd llvm-project
git sparse-checkout init --cone
git sparse-checkout add llvm/utils/vim
Would we create one separate repo for every extension? Vim, Emacs, Code, etc? Or one for all?
Not sure what “the proposal” means at the moment.
But I would also vote to leave the canonical source for those files in llvm/utils/vim. Should be easy enough for someone to grab those files regularily and create a “release” with them in a separate git repo or maybe someone can setup a github action that just copies them to the separate git repo on every change?
Or be part of the build process, and clearly separated at install time?
@MaskRay Did you hear back from the neovim community?
@rengolin I think at least for neovim we’d need an extra repo.
The way most Plugin manager work is by just providing a github repo url.
We might (?) be able to have a few plugins at the top level but I guess it would
quickly become hard to keep track which files correspond to which Editor,
beside of potential naming conflicts.
I missed the original notification. And +1 to what River said. The vscode plugin repo is effectively a read-only view of the source in the monorepo, kept up to date automatically via GitHub actions. I made another one like it for linguist like that too where submodules are used. Goal of those repos are indeed just for tools/plugins that use repos for packaging without changing dev flow.
Biasedly agree. It means existing flows all work. One could even tag revs corresponding to releases in this repo too.