-
Notifications
You must be signed in to change notification settings - Fork 874
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tabbed indenting #454
Comments
There is an issue for reordering use statements. It's a fun one, too. Agreed on the longness of the use statements. We should probably once again wrap on ideal width. We should do the same for functions whenever possible. Note that The chains using spaces instead of tabs seems to be a proper bug and deserves its own issue. About using visual indentation: you're correct that it's not possible to switch to block indentation in a lot of places. I'm sure this will be added at some point, I just don't know how prioritized it is for the other contributors. Personally, I'm focusing on formatting additional items more than the configurability of things. |
I don't want to go back to using ideal width for stuff - it looked weird when a whole file was one width except some odd bits and pieces. I found that I didn't like the long import lines at first, but got used to them. Yeah, we should add configurability for stuff like block indent in more places, but its not a priority for me either - I'd rather focus on getting the defaults looking really good and being able to avoid crashes, etc. Patches welcome for this stuff though! At some point I'll work on RFCs for more stuff and if there is demand then for certain options I'll work on them (like I did for function defs). |
I started out trying to make rustfmt work with the philosophy of "it ain't broke, don't fix it". But other than for line length, it turned out to be really difficult to judge if code obeys a set of rules, rather than reformatting it. Even with line length, it is a bit of a pain because of the mapping you have to do from lines to AST nodes in order to see if you should reformat or not. I fear that this implementation of rustfmt will never be able to operate in a mode where it leaves stuff alone unless it overflows. Two possible solutions: you only run rustfmt on small bits of code at a time (there's an issue for this already, and it shouldn't be difficult to implement); or we implement enough options that you can find a set close enough to what you want and always format everything (maybe with a dusting of |
Thanks for clearing that up, maybe I'll take a look at implementing some config options if I can get the time. When I said "roughly as it's currently formatted", I simply meant that I wanted a config that would result in similarly formatted code - I certainly like that rustfmt is opinionated and will reformat whatever it sees, I just very much dislike visual indenting in any form :p I wasn't able to find the issue for the use/import statements, could someone link that for me? Also, side question... Using #[rustfmt_skip] presumably means your source will only compile on unstable, is there any way to make use of it without sacrificing the ability to compile with stable? |
https://github.com/nrc/rustfmt/issues/298 I guess so. I think the only way round it is scoped attributes, I should make an RFC for that... |
Visual indenting seems to be sneaking in and I can't quite get the style I want... Apologies in advance for how bad this issue report is going to be.
test.rs
Generally, I'd want rustfmt to leave the source roughly as it's currently formatted, except that it would fix up and wrap some of the long lines. (note this is hard-tabbed)
diff
What it actually does is introduce visual indenting in various places...
rustfmt.toml
Notes
use std::{...}
line gets visually indented rather than block/tabbed. There doesn't seem to be a config option for this?fn some_func
declaration formatting starts off fine, but then it goes and indents the->
return part visually.some_call
visually indents its arguments.fn_args_layout = "Visual"
becauseBlock
is too vertical.Tabbed
probably describes what I'm looking for best. Also note thatBlock
doesn't even affectsome_call
for some reason?Block
would be what I'm looking for if it compressed more aggressively. Not necessarily a newline right after the opening bracket, etc.some_chain
at least seems to be indenting in tabbed style, but it indents with spaces rather than hard tabs.The text was updated successfully, but these errors were encountered: