I’ve sent an MR to Builder’s repository doing this work so all Rust projects can benefit from it, if you want to have a look.
So the problems with what you tried your MR were:
- you only need to add something in the global.ini when you need to match multiple code type (gtksourceview langage name basically). For example if you have a config for “c” then it’ll automatically match C files, but not headers because they are exposed through a “chdr” langage. So that’s where you’d do the link between “chdr” to “c” so it uses the config for “c” for C headers too.
- the “config” key inside rust/config.ini is only meant to have multiple configurations that can be picked from a file. But it isn’t mandatory to have one (especially since you don’t use in the command-pattern with @c@), and since here you’d be willing to pick the rustfmt.toml from the project, then it doesn’t make sense to have an empty placeholder rustfmt.toml in the beautifier config
- the beautifier acts on a temporary buffer containing the text selection, which is the file you get with @s@. But
cargo fmt acts on a whole project, not a file, even if you use
cargo fmt -- @s@ because it only accepts options for rustfmt, not input files. So you’d need to use
rustfmt directly instead.
- then, due to the temporary buffer being out-of-tree, rustfmt can’t find the project’s rustfmt.toml (but that’s a problem that you didn’t even reach though). So here it needed to have Builder to change slightly its behavior, which I’ve achieved in my MR to Builder by setting correctly PWD to the file’s parent directory, so rustfmt can walk through the project directories and find by itself the rustfmt.toml. (well here I encountered https://github.com/rust-lang/rustfmt/issues/4660 so I had to walk the tree in a python script myself instead of letting rustfmt handle it)
Hope all that’s useful to you to know (and have rustfmt support in Builder, too).
If you want you can try the branch I linked, it works fine.