Forced rustfmt is a roadblock to contributing

One thing I have noticed recently, is that having a form of persistent undo really changes my willingness to experiment with large refactors because of the ease at which it makes undoing those changes.

While it's theoretically possible to make rustfmt play nice with the editors concept of the undo stack, by injecting the difference into the editors undo stack. This sort of thing requires a lot of coordination between applications & as it is running rustfmt currently just truncates the undo stack, since my editor isnt able to apply deltas atop the externally modified files.

Anyhow, sort of a bummer at times.


The truly persistent form is called version control.

But yes, it'd be amazing if editors could integrate external formatters with the undo stack. Though said undo stack is still often finite; I lost some work a couple days ago to a cat walking over my keyboard while I was asleep and overwriting some code that hadn't been vcs committed yet with enough edits to fill up the undo stack.


Atom does.

If it detects external changes (and you don't have unsaved changes) it automatically loads them, and the load is treated as one frame of the undo stack.

I think as far as their delta rope goes, I think Atom just adds a "Remove everything and then add this entire new content" step. Not sure how well it scales with very large files.


Another example for rustfmt ignoring human judgment and thus making code less symmetric and harder to parse at a glance: here we have 4 very similar methods that ought to be formatted consistently, but rustfmt insists on using one-line-argument-style for 2 of them and multi-line-argument-style for the other 2.

  1. I would suggest that discussions of changes to rustfmt should probably be in a separate thread from discussions of rustfmt usage in CI.

  2. I remain convinced that line length is a terrible heuristic, and line complexity (e.g. "maximum nesting depth") would be a better one, which would be independent of the length of any one token.


Because I just had to do this myself, the command is simply

git filter-branch --tree-filter 'cargo fmt' -- origin/master...

I believe this should even deal with merges etc. correctly, though I have only tested it with a linear history descending from origin/master.