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:

quoted

-		/* 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