[RFC] Separate LLVM Vim utils into its own repo

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?

1 Like

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.