I use my own IDE for Rust development. Recently I noticed that other people are also using my tool. I do not like rustfmt work so generally do not use it. However, other people may like it, so question is - what a value of format-on-save for you? I've already integrated rustfmt with my IDE, so I am interested in automatic applying formatting on save.
If you think that the feature is valuable, how to better implement it?
use piping mechanism of rustfmt before save
save first and then call rustfmt with the file name
Sure, I need to decide what to do with errors and also how to resolve the concurrency issue. Any feedback is valuable.
Using an auto-formatter means I don't have to think about making formatting decisions that, in the end, aren’t very important. (I don’t agree with everything rustfmt does, but it’s better than not having a formatter.) Format-on-save, specifically, means I can quickly get the code into the formatted state for further editing in context of correct rather than incorrect formatting; if auto-formatting was harder to achieve, I’d end up spending more time on roughly indenting lines so I can read what I’m editing. I can do that — have done so in the past in other languages — but I don’t want to.
Note that one of the flaws of rust-analyzer’s usage of rustfmt is that in some cases, rustfmt will partially format the file and report an error, and rust-analyzer, in those cases, will discard the partially formatted work (issue). I recommend making sure that your integration does not have this problem.
I would find a format-on-save very annoying. You write code, close/save file, then re-open and the code is different? In my vim, I execute the command to format the code. Then I can see the results. See the error if it failed. Undo if I want. Modify formatting if I want. Then save and when you open it is the same as when you saved.
Maybe implement a "format" command that can be called when the user wants.
I agree with the opinion. Anyway, the implementation was fairly simple, so I added it. But yes, the feature is optional, and I have rustfmt installed only on one of my boxes.
That seems like a difference in workflow that makes format-on-save worse for you than for people that do like format-on-save. In most editors you would never do save+close, but rather only do save, which would immediately show the formatted version and preserve the ability to undo the formatting using ctrl-z (and see rustfmt errors if rust-analyzer actually surfaced those errors). But I can understand that if you mostly do save+close format-on-save would be annoying.
Currently, I set to format on save for projects I do for this forum. Some people really enjoy rustfmt work. But I really surprised on people liking rustfmt.
People don't like fustfmt, speficially. People like consistency.
I would gladly accept some ugly (in my POV) formatting that rustfmt does if I wouldn't need to learn new formatting rules for each crate that I may want to use to contribute to.
It doesn't even matter whether that formatting is “beautiful” or “ugly” (that's thorughly subjective evaluation), what matters is that it's exactly the same in all (or, at least, most) crates.
However I would prefer the formatting style helping me to read (my) code faster. So, I only partially agree with you here. It gives me another thought to apply the standard formatting only in a published code keeping it my formatting internally.
What I actually do is just type :RustFmt when I want to format in my editor but not till I am ready. Usually after doing so work, I type :w to save and let the analyzer do it's thing first, then if everthing is OK I type :RustFmt and then :w again.
I can't work with terribly formatted code like minified js so having good enough formatting is mandatory. But if I format them manually I'd naturally seek the best formatting option. After that I'd need to persuade my coworkers, make an agreement with them, and persuade myself back that the conclusion is acceptable. I don't like that much.
Instead, I choose not to seek the best formatting option myself. Rustfmt output is decently workable unlike minified js. I usually write a good chunk of code with minimal spaces and focus on other editor tab or the terminal. After I back to the code I wrote it is already formatted automatically with autosave. Since I don't care much about formatting myself I even turned on most inlay hints. They're rarely useful for me but it doesn't hurt.
And thats… drumroll… the style that rustfmt enforces. Because that's how the majority of code that you would ever see is styled.
So now you would need to remember two distinct code styles and would [try to] not forget to change the styling when you move code from one place to another.
This may work for some projects that are, very explicitly, internal-only and are, also very explicitly, prefer to duplicate things rather then import them (glorified NIH approach).
In some [pretty rare] cases that's a good idea. Most of the time… no.
I went from super old-fashioned "I type my stuff properly formatted" (like we did decades ago) to "I auto-format before committing" to "I press ctrl-s to format (and saving is a welcome side effect)"
It's a matter of personal preferences / personal workflow.
Yeah. I went through formatting wars with myself alone using C in the past. Tabs, 4 space, 8 space. Where to put braces or newlines on if blocks, gcc vs linux ...etc.
When I started with Rust I decided to give up in the beginning and just let rustfmt fix it and now I don't think about it....except late at night when I worry that the obscure trick I read somewhere, maybe mara? that showed using rustfmt on code and it changed the logic... I know it was obscure, a code I probably would not write, but I cant remember what it was or what blog it was on so I can be sure that the bug was fixed or that I won't write something to trigger it......
It is usually not my concern. We have a release engineer who does anyway source code review to remove any foul language commentary and debug messages, and other stuff which can lead to breaking our code.
I use apheleia for Emacs to format everything, Rust or otherwise. I really like the smooth way it works:
Run code formatters on after-save-hook, rather than before-save-hook, and do so asynchronously. Once the formatter has finished running, check if the buffer has been modified since it started; only apply the changes if not.
After running the code formatter, generate an RCS patch showing the changes and then apply it to the buffer. This prevents changes elsewhere in the buffer from moving point. If a patch region happens to include point, then use a dynamic programming algorithm for string alignment to determine where point should be moved so that it remains in the same place relative to its surroundings. Finally, if the vertical position of point relative to the window has changed, adjust the scroll position to maintain maximum visual continuity.
Most of the time, I can save and just keep editing the file without the least disruption.
While true, there are some inconsistencies introduced by rustfmt like match statements with varying pattern lengths getting some one-expression and some block-style arms where locally breaking line formatting to preserve the visual consistency of the same style would be better. (Always block blows up trivial things way too much to be used to enforce consistency).
At least that was my initial scepticism a few years back. While true, I now see this also as a way of rustfmt pointing out code that may be hard to read, that should have additional abstractions and separate methods that make the code more uniform. In a sense it's a proxy for surprise factor, uniform code is boring. Boring code is good. There's rough edges, of course, which do not fall into this category and respective issues open for configuration that would address these outliers but as said, an engineering tradeoff of ugliness for boringness is fine.
taking the insert position into account to avoid merging a partial line into the following one ,
recognizing broken syntax and bailing early enough that you don't reformat a bunch of unrelated code,
while still recognizing in progress but not completely broken code and still being able to reformat that so it's still readable, and
adding a separate undo state for auto format changes in case it understandably messes up regardless
Basically, you need to build a completely separate logic for formatting that agrees with rustfmt enough to not be annoying but also is editing aware, which is a huge lift. It's nice when it works, at least!
They also autosave pretty aggressively (not while editing) and run rustfmt then by default, so you are pretty much always seeing what you are committing even if the auto format is wrong.