On 2025-06-19 at 21:31:03, Collin Funk wrote: > From what I remember, clang-format is not at all stable between > releases. Newer versions will produce different output than old > ones (usually better, but that does not matter). > > For the reasons that you already mention, it ends up being a chore, in > my opinion. I don't think we should expect everyone to build/install a > clang-format version that is newer or older than what their distro ships > with, just to align the output with the project. Yeah, then in that case, we probably want to ship some sort of container and script that can do that. Our default Rust target is Debian stable, so that seems like a decent target if we need to pick a distro. It's also a very common distro used in containers, so it's widely available to contributors using container-based development environments. I still think that if we're going to have this functionality and expect it to be used, we need to make it the default, build appropriate tooling, and check it in CI. If it's not fire-and-forget, people won't use it. > If you wanted to be help avoid badly formatted patches adding a .vimrc > and .dir-locals.el file would cover most people, I think. For Emacs, the > .dir-locals.el would be something simple like: > > (c-mode . ((c-file-style . "linux") > (fill-column . 80) > ((indent-tabs-mode . t)))) > > At least with Emacs it is easy to type things that break these rules. So > one can avoid diffs like this, which clang-format would produce: > > > - /* Warn on any additional signatures, as they will be ignored. */ > > + /* Warn on any additional signatures, as they will be ignored. > > + */ > > I assume this is similar for vim, but I do not use it enough. Certainly there are a lot of Vim and Emacs users in this project, but there are also many people who are not. I use Neovim myself and still have to deal with wrapping lines at 80 characters. I also don't think Vim actually honours per-directory configuration like `.dir-locals.el` by default without turning on the `exrc` option, which is rightly documented as a security risk. -- brian m. carlson (they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
