[RFC] Separate LLVM Vim utils into its own repo

Hi all!

I’m writing to propose moving the LLVM Vim configurations, currently at llvm-project/llvm/utils/vim/, out of the monorepo into its own repository.

llvm/utils/vim currently contains useful settings for people using vim-family editors to work on the LLVM project:

  1. Filetype detections for .ll, .mir, tablegen .td, and lit config lit*.cfg files,
  2. Syntax highlighting, indentation, and some other default vim settings for those file types,
  3. A vimrc file that suggests coding style settings for working on the LLVM C++ codebase.

To utilize these configurations, one must manually copy/link the directories and files to their vim config directory. And copy-pasting selected parts from the inspirational vimrc file.

This has some major drawbacks:

  1. Low awareness: The configurations are buried deep in the monorepo. It’s not easy for new community members to find and use them, and more importantly to update and improve them.
  2. Hard to install/update (though admittedly probably not very frequent): As mentioned earlier, using the configurations now requires cloning the entire llvm-project repo, and involves manual steps every time they get updated.
  3. Limited functionalities: This also means our hands are tied when providing useful configurations. For example, the vimrc file is only provided as an inspiration, because we don’t have the modularity to turn specific settings on or off based on user preferences.

A separate llvm-vim repo would make the vim util much easier to live on and work on:

  1. Installation flexibility: While you can still copy/link the files directly to use with vanilla vim, a separate repo can be used by all modern and modular vim plugin managers (vim-plug, vundle, packer for neovim, etc.). Installing could be as simple as adding one line, and updating as one vim command call.
  2. A separate repo is easier to find, raising awareness and interest to update and improve the vim-integration.
  3. As a vim plugin, it opens up opportunities for more vim integration that can be controlled by users, for example by vim global variables.

The initial transition should also be straightforward: taking the llvm-project/llvm/utils/vim directory out as-is makes it a usable vim plugin. I found GitHub - rhysd/vim-llvm: Vim filetype support for LLVM (including official files) while working on this proposal as an example, also as a point that this is useful and desirable.

Let me know what you think!

3 Likes

Hi,

happy to read about your proposal. I’m not a direct LLVM contributor, so I’ve always wondered if I use LLVM+(neo)vim the wrong way. While trying to set up nvim for LLVM I stumbled into a few GitHub repos like the one you linked, but they all looked unofficial and outdated. I would be happy if I just can add another link into my plugin section for the official and maintained llvm-vim repo instead of having to copy over all the files. To be fair the LLVM documentation somewhere mentioned that copying everything over was the official way of doing it, but I certainly never updated those files and it’s not part of my server setup script, so I would need to dig up that documentation for every new server which I set up.
That seems to resemble pretty much what you wrote, so I would be glad to see such an improvement.

Thanks for creating that post!

When i was searching for theses config files, i have found them randomly on a google search.
It will definitively easier to move them to another repo (easier to clone, and find on a seach engine/github).
I also think that we need to create some documentation around it (related plugins and their configuration like nvim-lspconfig).
Splitting config files for Vim and Neovim users will also be helpful.

Also making sure that people using (Neo)Vim will find theses config files nearly as easy as finding VSCode LLVM related extensions (we are not a majority using (Neo)Vim but it’s still important in my opinion).

+1 for splitting the config into another repo on the llvm github org. I’m using the one you linked because of this issue as well

Another +1. Similar to what you described, I created my own separate repository ~6 years ago. That’s been working fine, but it would be nice to have something canonical that everyone can use and is kept up to date.

If llvm developers decide to reparate llvm vim utils into its own repo, please do the same thing for llvm’s emacs uitls. For the same inconvenience of using such a monorepo with Emacs, I also create a separate repository for my own use. It would be great to separate this.

I am in favor of splitting out both vim and emacs utils into a separate repo. What should we do about releases? Should the new repos follow the same release schedule as the llvm-project repo or do something different? Do we even need releases for this?

Most vim plugins I’m aware of don’t use releases, most folks track HEAD and update occasionally. So I don’t think releases are necessary

It is odd that you want to split up the monorepo. I had a brief look at the vim plugin and there are some llvm keywords for highlighting. When the next keyword will be introduced somebody will likely also update the editor plugins. Is the real problem that the plugins are hard to find? Bad location and bad advertisement?

Nearly all vim plugins don’t use releases. It also looks like that the vim config in the monorepo is not at least somewhat maintained. It does not make sense to even have a release schedule for the vim files, if nobody is working actively working on them.

Why do releases matter? If you want the latest and greatest then just take the version in main. If the concern is repo size, sparse clones and checkouts are a thing these days.

My understanding is that the vim (and sounds like emacs) tools for loading plugins don’t work well with the monorepo layout and would work better if the plugin was in its own repo.

Hi @zixu-w ,

Do we really want/need yet another repository to maintain? Especially, given that the existing set-up for Vim in LLVM is rather small. While I’ve only contributed one patch there, that fact that that these files are inside llvm-project made it very straightforward for me.

What about other editors? If we have a separate repo for Vim, then should we have a separate one for Emacs, VSCode, JEdit, Kate? If config files for editors are split between llvm-project/llvm/utils/<editor> and llvm-<editor> repositories, then that’s going to be very confusing.

I feel that there are alternatives that we could explore first:

There are many things “buried deep in the monorepo”. But the monorepo is also the main place where people look for LLVM related things (and endorsed by the community). We can (and IMHO should) improve the visibility of these things by improving our documentation first.

Have you explored the possibility of cloning a subdirectory from various Vim plugin managers? Is a separate repo definitely the only option? I am thinking that perhaps we could try a separate LLVM sub-project first. Something that would contain ALL configs for ALL editors (e.g. llvm-project/editors).

I am concerned that a separate repository will actually make the Vim config less discoverable. Since the switch to monorepo, I expect all the essential components of LLVM to live inside llvm-project. But perhaps others have different view.

I am not going to block this effort - I can adjust my workflow accordingly and also see that a separate repo would benefit me too. I’m just concerned about the overall cost of this move and would like for us to:

  • explore the alternatives first,
  • make sure that all editor configs are equally easy to discover,
  • avoid fragmentation (through proliferation of repositories) and inconsistencies (by storing configs for various editors in completely different locations).

Thanks,
-Andrzej

1 Like

@jpienaar @River707 Is this proposal similar to the vscode-mlir repo that you maintain? Any advice for which way to go here?

I don’t know enough about vim configurations to have all of the context here, but it does feel similar in some ways. For context to others, we maintain vscode-mlir effectively as a deployment repository for the MLIR VSCode extension (which at this point supports language tooling for 3 different languages, MLIR IR, PDLL, and TableGen). Having a different repository has greatly simplified the ability for us to package/deploy to VSCode extension marketplaces, and provide an easy integration point for users that don’t develop the extension but want to use it. Something that is important to note is that the vscode-mlir repo is “deployment only”. All development takes place in the monorepo(the vscode-mlir README makes this clear), with the repo occasionally integrating the necessary sub-parts of the monorepo and stitching them together for a user-ready package (see the integration workflow here). This means we still add functionality in the places it should be (e.g. when I added tablegen syntax highlighting) and use all of the same development practices as everything else in the project, but users get an easier interface point. The maintenance burden on the vscode-mlir repo (at least for me) is effectively non-existent. After the initial phase of getting the workflow setup, I rarely touch the repo. Not sure if that helps, but that’s been my experience shipping the vscode extension for MLIR.

– River

Why not move them to GitHub - vim/vim: The official Vim repository? Eventually new Debian packages would be built, Ubuntu would copy them, the packages can be installed via “apt install vim-runtime” and you would get a working vim configuration for LLVM without even thinking.

1 Like

-1. That’s what symlinks are for. We update the IR too frequently to keep upstream VIM up to date. I much prefer setting up the symlinks once, then being done until I move to a new machine every few years.

Upstream vim would be better. A random 3rd repo would be the least likely to be updated scenario

??
That’s exactly what I proposed.

There are licensing considerations to move code from LLVM to the VIM repo. I am not a lawyer, but I’m pretty sure that wouldn’t be something that someone could just do.