Line and indent width

[nrc]

Decide on the options and defaults for the maximum width of lines and indents.

Rustfmt currently has the following options:

    max_width: usize, 100, "Maximum width of each line";
    ideal_width: usize, 80, "Ideal width of each line";
    tab_spaces: usize, 4, "Number of spaces per tab";
    hard_tabs: bool, false, "Use tab characters for indentation, spaces for alignment";

The style guide specifies a maximum line width of 99 chars and 4 spaces (no tabs) for indentation. make tidy enforces 100 char width for the Rust repo.

Mostly these defaults seem reasonable. Points to discuss:

• 99 or 100 char width,
• 'ideal width' concept,
• which options should remain,
• names of options.

Notes:

• ideal width is not really used by rustfmt any more, in retrospect it was a bad idea. The only place it is used (I think) is for comments. I do think wrapping comments at 80 chars is nice, since reading prose is easier in narrower columns and the solid text of large comment blocks looks bad. It might be nice to keep the comment width at 80 and either remove the option to change it, or rename the option.
• the 99 chars thing is to cope with diffs in 100 chars or newlines in terminals.

[nrc]

On the indent width issue, some people prefer 2 spaces, but 4 is the most common in the eco-system. OTOH, 2 causes less rightward drift. Hard tabs are very uncommon.

[joshtriplett]

@nrc Personally, I'm a fan of the policy in the Linux kernel that suggests combating rightward drift by refactoring code, such as extracting functions or flipping conditions (e.g. if (error) { return ... } if (other_error) { return ... } rather than if (success) { if (other_success) { ... } }).

I also think 2-space indent doesn't provide sufficient visual differentiation of blocks.

So, I'd advocate 4 spaces.

[joshtriplett]

Reposting my comment from #2:

We need to define what to do in cases where wrapping at 100 must not happen. For example, taking inspiration from the coding style guidelines for the Linux kernel, I would advocate not breaking any string constant intended for printing to humans into multiple concatenated constants for word-wrapping; otherwise, someone searching for an error message in the code may not find it. (Wrapping immediately after a '\n' works, though.) Given this, though, rustfmt also shouldn't do silly things like wrapping a ; or ); immediately after the string constant onto another line.

Similarly, within a comment, a fixed-width block shouldn't get word-wrapped automatically. For instance, if someone puts a carefully formatted ASCII-art table or diagram into their comment, with a width of 120 characters, rustfmt should not mangle that. (It would presumably need to appear between triple-backquotes or similar.)

Finally, I think this needs associated reasonable procedures for where to break lines, how to indent continuation lines, and how to align those continuation lines. Those procedures might not need to appear within this RFC, but this RFC should acknowledge the need for them, and rustfmt shouldn't enforce wrapping (or un-wrapping) if it doesn't have a good way to handle alignment. (Simple example: whether to align operands of a binary operator, and whether to wrap before or after the operator. Another example: when wrapping a long if or while condition, where should the continuation line get indented to, and will it avoid potential confusion with the following body lines?)

[nikomatsakis]

Some comments from #2:

• @alexcrichton likes 80 spaces
• @wycats wanted 2-space indents
• @aturon is maybe interested in 2-space
• @nikomatsakis kinda likes 'em too, but worries about deeply nested expressions
• @wycats suggests we could address that more directly

[nrc]

Reminder to self (and others) to read the comments on #2 as well as the above summary

[Diggsey]

Two space indentation makes it difficult to see which lines are at the same indentation level when they're not very close together (Also this is why tabs are good, you get to choose an indentation level that suites you without modifying the code and thus avoid this entire argument, although it's a bit late to change to tabs...)

Overall I wish the style was exactly as described here: https://ubsan.github.io/style/

The stated goal of being "easy to manually format" is very far from being met with the current style, and visual indentation is horrible, both when writing and refactoring code, even if you're lucky enough to have an editor with support for it (I've never actually encountered an editor that handled this well, probably because of the inherent ambiguity in visual indentation...)

The way I see it, it's a trade off between being subjectively very slightly prettier in some cases (the current style) and being objectively simpler in all cases (ubsan's style). The latter has the distinct advantage of having almost no additional edge cases to consider, having no ambiguity so editors can easily do a good job of refactoring without having to reformat the entire file with an external tool, and a big one: eliminating unnecessary rightward drift!

[solson]

@ubsan's also expressed interest in 2-space indent in the past. Not sure why it didn't make it into that document - trying to be more status quo to reach more people, perhaps? I'd still like to find out what the community at large thinks about 2-space indent, after seeing arguments from both sides.

I haven't read that style guide in full but in the past I've mostly agreed with ubsan, especially regarding the style rules being simple and as free of edge cases as possible. I guess we should have another issue dedicated to visual indentation versus block indentation, and whatever else is important in ubsan's guide.

[joshtriplett]

I personally find 2-space indents much harder to read, because they make indentation levels less distinct.

(Also, some of the comments in #2 mention "2-space tabs". For the sake of clarification, I'd suggest talking about "2-space indentation" or similar, to avoid confusion with tab characters. We seem to have widespread consensus to avoid tab characters.)

[joshtriplett]

@Diggsey
I like the majority of those linked style guidelines. I have a few quibbles with some of the items about where to break lines, but most of those get superseded by the question of whether we should have a maximum line width at all.

The only item I found extremely problematic in those guidelines: the use of braces around if conditions and similar (as opposed to the body of the if). I find that quite confusing and visually ambiguous; it makes the condition look like the body.

[Diggsey]

@joshtriplett The guidelines say not to use extra braces around if conditions, etc.

[solson]

@Diggsey They contain examples with braces around if conditions.

EDIT: specifically in https://ubsan.github.io/style/#indenting

[nrc]

Could we try and keep this tread on-topic (the basic parameters - indent, width) please. I created #7 to discuss the general look and feel of code.

[joshtriplett]

@nrc Agreed. However, indentation and code width do interact very closely with where and how to break lines, so those topics will necessarily overlap.

[strega-nil]

@solson

@ubsan's also expressed interest in 2-space indent in the past. Not sure why it didn't make it into that document - trying to be more status quo to reach more people, perhaps?

Yep, to reach more people. I think that's the best as a default. I still prefer 2 spaces, although, if we wrote Rust like I would in my perfect world...

pub const fn foo () -> u32
{
  if bar() {
    let x = std::mem::size_of::<T> ();
    x.method ()
  }
}

Edit: I was going through a phase... left for posterity purposes to see what awful style GNU had pushed me to.

[strega-nil]

As to linewidth and indentation:

99 chars recommended, 79 chars as a backup, and "just do what your project is doing" otherwise. (edit: I personally prefer 79, but I think 99 is better as a standard)

I'd prefer 2-space, I don't mind 4-space, and I don't mind 8-space|1-tab. I am completely uninterested in any style with an odd indentation. I doubt anyone wants to use tabs, but I could use them happily enough.

Edit: I realize when I say "100", I mean "99", and etc. Changed to reflect that.

[bradleybeddoes]

I'm new to Rust dev and using it mainly for personal projects, day-to-day I'm largely working with Ruby. I've been using rustfmt extensively and whilst the 4/100(99) is fine I'd personally prefer 2/80(79). I find this much nicer to work with on a laptop as it maintains ability to have still have 2+ vertical vim splits in full view.

Just wanted to also share this guide, I've found it useful in the Ruby space https://github.com/bbatsov/ruby-style-guide and it is what Rubocop (https://github.com/bbatsov/rubocop) enforces.

[bruno-medeiros]

Overall I wish the style was exactly as described here: https://ubsan.github.io/style/

I quite like this style as well. I've been using essentially an identical style in Java code as well, even before I knew about the link above. It's a much simpler and orthogonal style, the guiding principle - at least what I like about it - is that it treats parameters lists and type parameters like any other block. In other works, the "()" and "<>" blocks are indented like just "{}" blocks -> you insert newline and then add one level of indentation.

The alternative (that I saw somewhere I can't remember), where you indent parameters like this:

fn my_fancy_function(name_one: String, 
                     name_two: String,
                     option_one: bool
) {
    //...
}

is just horrible 😨

[fabric-and-ink]

My 2 cents: I worked a long time in a code base with 2-space indentation and must say that I prefer 4 spaces now. After about 4 indentation levels it begins to get hard to distinguish between individual levels with a 2-space indentation. Therefore a 4-space indentation gives me a much better overview between the indentation levels. On the other hand, Rust code could save some screen space by indenting only 2-spaces. (I am thinking of the tendency of rightward drift.)

Concerning the maximum width, I prefer 80 characters width, since my programming environment is adapted to this width. (Vertical split view in vim with the matching font size to make best use of the screen estate :).)

[bruno-medeiros]

Concerning the maximum width, I prefer 80 characters width, since my programming environment is adapted to this width. (Vertical split view in vim with the matching font size to make best use of the screen estate :).)

Vertical split? Oh.... now things are making a lot more sense! I was indeed quite wondering why Vim/Emacs users (and languages like Ruby in which the community/userbase tended to favor Vim/Emacs moreso than other languages ) tended to prefer 80 characters max, whereas full IDE users (Eclipse/IntelliJ/VS, etc) tended to prefer bigger max line widths, even though those IDEs generally have less editor screen space available, due to prevalence of other UI views (Project Explorer / Navigator, Outline, etc.)

[joshtriplett]

@bruno-medeiros Especially with current widescreen displays, vertical split works quite well, and tends to produce two windows of about the right width.

[fabric-and-ink]

@bruno-medeiros Once you use a vertical split, you don't want to miss it 😄

[nrc]

Comments from #2

@brson

I'm not sure I understand what "A comment should be wrapped at the minimum of the 80 character comment limit and the 100 character line limit" means. Since the minimum of 80 and 100 is 80, it seems to say "a comment should be wrapped at 80 characters".

Personally I'm fine with these rules. I think the rationale for 100-char lines and 80-char comments is as reasonable as might be expected; though even though I advocated the 100 character limit I do find myself frequently annoyed at long-lines on my split-screen 13-inch laptop.

I know there's a vocal contingency that thinks 2-space indent is correct for Rust, and that would ease the need for 100-char lines. I do think it's tempting to take this (probably last) opportunity to switch to 2-spaces/80-chars. It may be worth reformatting all of Rust with these settings to take a look at something concrete.

@steveklabnik

The standard library largely uses an 80 width indent, it seems. Or at least, I know that I've wrapped to 100 and had @alexcrichton chide me for it 😄

@steveklabnik

Yes, to echo what @brson said, there's two camps:

• 100 columns, four space indent
• 80 columsn, two space indent

The first was semi-arbitrarily chosen a while back, and is what most things do today. However, as I mentioned inline, the standard library seems to often do four space indent, 80 cols, which is the worst of both worlds.

Ruby uses style number two, so I'm happy with it, but I've mostly been using style number one, since it was the largest contingent of people, and I'm happy with it as well. To me, this is the most core question: which of these two options should it be? I'm not totally sure about making comments different from other kinds of code; I'd prefer the simplicity of one style for everything.

@joshtriplett

(Obligatory acknowledgement that this is the bikesheddiest of all bikeshed topics.)

@steveklabnik

I agree that comments shouldn't follow different rules.

I've become increasingly convinced, however, that we shouldn't have a fixed width at all. I do think we should break lines in logical locations, but I don't think I've ever seen a case where a line break that made sense with a line width of 80 wouldn't make just as much sense to preserve with a line width of 500. For instance, if you have an expression like this:

if complex_expression(x)
   || complex_expression(y)
   || complex_expression(z) {

I'd suggest wrapping it that way no matter how the width of complex_expression compares to the target line width. Even if you have a line width of 500, I wouldn't put all that on one line, because wrapping it that way shows the similarity (complex_expression) and differences (x, y, z) between the lines.

Conversely, for an expression like this:

                        if an_interesting_function(x) == TARGET_VALUE_FOR_X
                           || an_interesting_function(y) == TARGET_VALUE_FOR_Y {

I can't imagine a scenario where that code becomes clearer by putting a line break next to the ==.

Likewise, no matter how far to the right your indentation gets, I don't think it makes sense to wrap println!("{}", x); onto two lines (the second containing x);).

Unfortunately, the concept of "logical line breaks" makes an automated formatting tool like rustfmt much more complex.

@alexcrichton

Thanks for the cc @brson!

I personally fall very squarely into the "80 column hard limit" camp. I personally work on a relatively small screen (13" laptop) where once I have 100 columns of code on my screen it ends up taking quite a bit of screen real-estate. Additionally, I've found that 80 columns works very well for basically all other tools in existence: diff, github, pastes, browser windows, etc. All that's really just a long winded way of saying that I believe I'm actively more productive with 80 characters as in the long run I can just see more on a screen. I'm sure others feel differently though!

I also agree with @steveklabnik that there are two camps here where the column limit is closely related to the tab number as well. I personally have no opinions on this in the sense that I'm perfectly fine with either 2 or 4 space tabs plus and 80 column limit.

As @steveklabnik also mentioned the prevailing style of the standard library is 80 columns, but I don't think this is consistently applied (or in the compiler as well). I think it may be a data point for what the style would look like, but I wouldn't necessarily hold it as "precedent to make a decision one way or another".

Now finally, I'll agree with @joshtriplett that this is indeed one of the most bike-sheddy topics available! Along those lines I don't want to represent a hard stance or anything, just offer my opinion. Whatever we choose I'll learn to deal with!

@solson

I know there's a sizable minority that wishes we would switch to two spaces because of Rust's tendency to have a lot of indentation levels (rightwards drift). I'm not sure how the wider community feels about that.

EDIT: Oops, should have read the out-of-line comments first. I guess we'll get around to discussing this again on a later PR.

@wycats

I'm a strong proponent of 2-space tabs. I am very interested in hearing from someone who believes we should standardize on 4-space tabs for some reason other than inertia and the status-quo. I don't totally discount the status quo argument, and am prepared to debate it, but first I'd like to identify whether there are any strong a priori arguments for 4-space tabs.

The TLDR of my position in favor of 2-space tabs is that Rust has a number of common constructs that produce indents (impl, fn, match, match arms) and also tends to have long function signatures, which necessitate some nesting of multi-line function signatures. Nested functions create an especially bad combination of rightward-drift-inducing features. In practice, 4-space tabs results in a fair bit of rightward drift and, to me at least, makes poor use of the available horizontal space.

Informal polling has revealed far more support for 2-space tabs than I initially expected (please do speak up if you're in favor), which has given me some impetus to argue that we should consider standardizing around them.

@aturon

FWIW I'm definitely interested in exploring 2-space tabs. This is our golden opportunity to do so, and there could be significant benefit.

I wouldn't say I'm a strong proponent -- at least, not yet -- but that's mostly because I haven't thought carefully through it. Like @wycats I'm curious to hear the fundamental arguments for larger widths.

@nikomatsakis

If we take status quo out of the equation, I am mildly in favor of 2-space tabs. Basically any time I have made the shift, I have found I like it better. It makes things like match in particular somewhat nicer. If nothing else, when I am not in a convenient editor I don't have to slam the space bar so many times. :)

I imagine the a priori argument in favor of 4-space is that it helps to avoid deep nesting. I do find my brain has a rather low "max recursion depth" and can get confused by deeply nested expressions and code. But I am not sure that the number of spaces used in indenting is the major contributing factor here.

I have no strong opinion about 80 vs 100 characters, but agree we should settle on one of those two. In the past Rust had a 78 character limit which I found quite annoying, but that was with 4-space tabs, and it was also without any kind of automated support for meeting that limit -- so mostly you only noticed it when make tidy ran, very late in the process.

@wycats

I do find my brain has a rather low "max recursion depth" and can get confused by deeply nested expressions and code. But I am not sure that the number of spaces used in indenting is the major contributing factor here.

If we want to encourage this, we could create a complexity or max-recursion lint that would target this problem more directly. I think the four-space syntactic vinegar is too bitter for "ok" cases to justify its impact on "problematic" cases, especially when more narrowly tailored solutions to that problem are available.

[gnzlbg]

I prefer 79-80 chars hard limit because I hate line wrapping. I work in a project that uses 120 char hard limit, and there are three situations where with more than 100 chars I get line wrapping all the time:

• three-way merges: that is, when one has two files and wants to git/svn merge them (into a result), being able to see both files and the result next to each other without lines wrapping is very handy (I use kdiff3 for this). This is possible on normal screens with 80 chars, but once you go to >=100 chars I always get line wrapping even on really big screens (20-22''). Since merging is a very bug prone process, I actually find line wrapping to be dangerous here.
• terminals: I often program through ssh sessions without x and using an editor in a terminal, and it is very rare to have terminals with more than 80 chars.
• laptops: I like my laptops to be "portable", which kinds of limits them to 11-13'' screens. I often program there, and most of the time while programming I have two vertical emacs buffers open side-by-side (sometimes to the same file, sometimes to different files). With 80 chars this is possible without line wrapping, with ~100 chars I get line wrapping.

2 vs 4 spaces: the recurring argument that indentation levels are easier to distinguish with 4 spaces than with 2 applies to 8 vs 4, 2 vs 1, 3 vs 2, ... I guess the question should not be whether 4 spaces makes it easier, but whether 2 spaces is enough or not.

For me, 2 spaces is enough to distinguish indentation. This doesn't mean that 4 spaces don't make it easier, but I have never had trouble distinguishing indentation with 2 spaces. I also work on a large C++ project that uses 1 space indentation level in some special circumstances (public/protected/private clauses in classes, : member_variable(initializer) in constructors, ...), and nobody has complained yet that 1 character indentation is not enough in these cases, but the sample size is small (20 people).

Having said this, I don't really mind about using either 4 or 2 spaces. My preference would be 2 because then I can see more code on the screen, but vertical "drift" is more relevant for seeing more code on the screen than horizontal drift. So I don't have a strong opinion here.

Those having trouble distinguishing indentation levels with 2 spaces, are you using a monospaced font for coding? Which editor, os, desktop environment,... are you using?

[joshtriplett]

I use a monospace font in a terminal. I find 2-character indent hard to distinguish when looking at large volumes of code; it provides less visual distinction between blocks, and in particular makes a block blend into the line immediately prior to that block.

Yes, 4-character indentation moves the code to the right quicker; I'd consider that a feature. If 4-character indent causes code to get too close to the right edge of the screen, that strongly suggests a need to refactor the code to avoid nesting blocks that deep.

[Diggsey]

I always use a monospace font too in several editors, it's obviously not hard to distinguish adjacent lines, but when you have a large block it can be difficult to match up start and end markers at a glance with only 2 space indents.

[gnzlbg]

@joshtriplett

in particular makes a block blend into the line immediately prior to that block.

I don't understand what you mean here, can you give a short example?

@Diggsey

but when you have a large block it can be difficult to match up start and end markers at a glance with only 2 space indents.

Thanks for mentioning this! I think I've never run into this issue because emacs colors each { } pair differently, which is a huge visual help, so I did not even think about this. Without that I can see how this gets more difficult as blocks get larger and how 4 space indents help. At least as long as the blocks still completely fit vertically in the screen, beyond that I would still need editor support to make sense of things (emacs shows the line of the open brace { when hovering the mouse/cursor on a close brace } but I guess most editors have something similar).

[wycats]

Speaking of which, does anyone know if there's an open bug somewhere for getting cargo new and cargo init to generate an .editorconfig matching rustfmt defaults?

This seems like a great idea that I could get behind! I'm a big fan of .editorconfig.

[wycats]

This isn't going to change at this point.

I didn't mean to reopen this convo! I just mentioned my original support for 2-space tabs to show some empathy with the desires of the original request.

BTW Github supports the editorconfig standard where you can set the tab width via specific files. I've enabled it in my repos. E.g. check this link where tabs are rendered as 4 spaces: https://github.com/RustAudio/lewton/blob/706913e749160357c222964ffa2da22244f4aa58/src/capi.rs

If we're talking about having tools reformat tab widths for personal preference, it's not technically difficult for tools to reformat "four-space tabs" to "two-space tabs", so I don't think this is a strong argument for making a change at this late date.

[joshtriplett]

@wycats I think there may be some ambiguity in terminology here, between (for instance) two-space indents and a tab width of 2.

Also, regarding cargo and editorconfig, there was such a proposal, which was closed: rust-lang/rfcs#2549

[wycats]

@joshtriplett YIKES! I definitely meant two-space indents not tabs 😱 .

Also, regarding cargo and editorconfig, there was such a proposal, which was closed: rust-lang/rfcs#2549

I think enough time has gone by, with enough additional adoption, that it may be worth revisiting, but if I want to see anything happen there, I should do the work of an RFC myself. I definitely didn't mean to relitigate anything here.

[cornfeedhobo]

I now agree that supporting tab indent is definitely a desirable configuration

I just want to point out that understanding for the impaired is a great start, but the fact that tabs is not the default makes their barrier to entry still tremendous, essentially locking them out of most opensource contribution, precisely because how few people grasp the nuances of this choice.

IMHO, if we can finally acknowledge this reality, we should make a strong effort to revisit the topic as a whole. Anything else is performative and, IMHO, a black mark on how Rust views it's role in the larger development community.

Edit: I probably should have kept this opinion to myself. Sorry.

Edit 2: for those still reading this, the reddit post worth reading

[ssokolow]

@cornfeedhobo

Given how customizable rustfmt is, and the existence of people who are opinionated enough to take an "either I customize it to my liking or I won't use it" stance, I don't think changing the default would be as beneficial as you think.

Hell, gofmt locks users into a single, specific style, and that prompted goformat to be written as a configurable alternative.

I'll restate my position: "The proper solution is to get rustfmt and its integrations to the point where people with accessibility issues can reliably, comfortably, and seamlessly reformat a project to their needs, work on it, and then reformat back to the project style before committing"

(Ideally, so seamlessly that they need never touch rustfmt or even see the project style. They just set a personal style that their editor displays and the project sets a project style that gets fed to the VCS. Not unlike how setting a browser to force a custom user stylesheet works.)

[trev-dev]

@theWebalyst the most important (and frustrating) consequence of using hard tabs is that hard tabs render as 8 spaces in many web contexts (including Github), which is the opposite of what you're trying to accomplish.

I personally advocated for, and would have preferred, 2-space tabs. Now that Rust standardized on 4-space tabs, I think sticking with the community look and feel is best.

Just my two cents - web interfaces that clumsily force you into a tab size of 8 and do not offer you a reasonable way to change that are an entirely different accessibility issue. You'd think that Github with all its splendor would get this.

For what its worth, aside from an editorconfig, you may tack ?ts=4 onto the end of a source file. That will get you the expected "4 space-like" formatting.

[LeSnake04]

Would you at least consider asking if the user prefers tabs or spaces when running rustfmt for the first time in a project and then create a configuration file with hard_tabs=true if needed.

I would prefer Tabs by default but asking the user directly is the best solution to avoid the discussion IMO

[ssokolow]

That assumes the first rustfmt run is in a context where the user can be prompted, rather than a situation like an "It's being run by an IDE that hasn't been updated to support this new rustfmt" situation... at which point, it's a choice between API breakage and resorting to a default.

(Or, for that matter, something as similar as some of the "prepare a new project and open up my gVim and git gui" shell scripts I and other people have written.)

Also, I don't remember there being a precedent for core/included-by-default Cargo commands like cargo fmt using interactive prompts.

[LeSnake04]

That assumes the first rustfmt run is in a context where the user can be prompted, rather than a situation like an "It's being run by an IDE that hasn't been updated to support this new rustfmt" situation... at which point, it's a choice between API breakage and resorting to a default.

(Or, for that matter, something as similar as some of the "prepare a new project and open up my gVim and git gui" shell scripts I and other people have written.)

Also, I don't remember there being a precedent for core/included-by-default Cargo commands like cargo fmt using interactive prompts.

Alternatively add a --enable--tabs option that adds the option to rustfmt.toml (and creates it when nessesary) and when run without option, it detected tabs and there is no rustfmt.toml (this could mean that the user is new to the language and might bc his indications got converted), show a message explaining that rust fmt converts the indication to spaces, but that user can set up cargo fmt the project to permanently use tabs by running cargo fmt --enable-tabs or attaching hard_tabs=true to rustfmt.toml or temprary with cargo fmt --tabs.

This shouldn't break compatibility, but users will get a feedback whats happening and how to to enable to the behavior they probably want, since this message should only pop op if rustfmt detected (a certain number or percentage of lines to avoid space users getting the message bc of accidental or pasted tabs ?) tabs, so users using spaces anyway aren't annoyed by the warning.

Or even better: it should just detect if the program uses tabs or spaces and automatically and select the indentation.

Finding out the preferred indention of a project should be fairly easy
If 90% of the first lines use Tab, the Dev very likely prefers tabs and fmt should use tab and if 90% of the lines use space, the dev surely prefers space. This should satisfy both parties !

[probablykasper]

@theWebalyst the most important (and frustrating) consequence of using hard tabs is that hard tabs render as 8 spaces in many web contexts (including Github), which is the opposite of what you're trying to accomplish.

GitHub defaults to 8 spaces, but you can change it in Appearance > Tab size preference.

For browsers it's not as easy to change, but that's not really a great argument against tabs since that's just browsers forcing an opinionated tab width instead of a developer forcing an opinionated tab width

[natehouk]

The entire point of rustfmt is to force viewers to view code exactly the way the author intended. spaces ftw

[ssokolow]

@natehouk But it doesn't have to be seen that way.

Alternatively, the point of rustfmt is to build the expectation that formatting can be reliably mechanically transformed and remove the expectation that formatting which can't be mechanically restored will be preserved, so that each author/viewer can view code the way they want to.

That's certainly the more accessible approach. Let someone with a visual disability reformat the indentation style to something that better meets their needs on checkout, and then reformat to the project standard on commit.

[natehouk]

@ssokolow tabs are a nightmare in vim.

[ssokolow]

@natehouk Which is why we need more first-class support for letting each contributor rustfmt to their preference before editing and then rustfmt back to project standard on commit.

...also, gVim is my editor of choice for everything, so that statement carries no "you don't know what it's really like" weight with me.

[natehouk]

@ssokolow I understand your perspective, but gvim is not default installed on any Linux/GNU distributions making that solution difficult in a real production environment.

Being able to easily automatically format to preference each direction would be ideal. Assuming spaces are default. While accessibility is important, it shouldn't be the default.

[ssokolow]

I understand your perspective, but gvim is not default installed on any Linux/GNU distributions making that solution difficult in a real production environment.

I don't see what gVim being installed or not installed has to do with anything.

I've used terminal Vim enough to know that the two are equivalent for talking about how good or bad the experience is with tabs and my point was just that I understand what the tabs experience is like in Vim/gVim.

Being able to easily automatically format to preference each direction would be ideal. Assuming spaces are default. While accessibility is important, it shouldn't be the default.

I never said it should be. I was just disputing your statement that "The entire point of rustfmt is to force viewers to view code exactly the way the author intended."

[hadrien-toma]

"Accessibility shouldn't be the default"

This is already very opinionated statement... which I completely disagree with 😕.

Accessibility should be the default 🤷♥️

[bjorn3]

How hard would it be to make accessibility tools properly handle spaces as indentation? If it isn't too hard (I did expect this to be much easier than the alternative at least), this would permanently fix the accessibility problem entirely without having to ask every single programming language that uses spaces to change their preferred indentation from to tabs and cause enormous amounts of churn and confusion (from code mixing tabs and spaces due to copy paste) during the transition. And would solve the problem for all legacy code that will never get updated to switch and where the author refuses to switch for whichever reason they have. Or if you are writing code in the github comment ui for that matter. (you can't insert tabs there as it causes focus to move out of the textbox to the next element in tab order)

[ssokolow]

The examples I've heard related weren't about accessiblity tools so much as things like people with visual disabilities setting a giant font size and as little as a one-space tab width.

[bjorn3]

I see. I thought the issue was about every space being pronounced by screenreaders individually, so for example to levels of indentation would give 8x "space" being pronouned. Was I wrong about that or is that also an issue.

For one-space tab width I guess a specially crafted font that uses ligatures to combine 4 consecutive spaces would work. That is something that would be more involved than just setting the tab width to 1 when using tabs for indentation though.

[lu-zero]

it is a closed issue and the argument about tabs for accessibility had been discussed already.

Some people use systems that consume spaces as indentation better some use systems that may enjoy tabs better.

The consensus is that tabs are the worst choice for the out of box situation for most and that fact is not going to change by repeating the same statements many times.

[lu-zero]

Re-read what I wrote and the thread again please. The people I referred to are those using those specialized tools.

[hadrien-toma]

Re-read what I wrote and the thread again please. The people I referred to are those using those specialized tools.

You are totally right, I misinterpreted "system" as users. So I agree with you about those facts. Sorry for the reaction, the underlying implications I highlighted make me a bit electric... 😩

I removed the message

[cornfeedhobo]

@lu-zero When it's a bad decision, it's completely appropriate for others to point it out, ad nauseam. Feel free to turn off notifications if this bothers you.

Edit: How is you repeating "it's been decided" any different? I've been around disabled engineers my entire life and you're repeating the same thing they have to deal with their entire lives, but somehow the disabled community is the broken record?

[calebcartwright]

It actually isn't appropriate, nor is it helpful, to continue repeating the same thing over and over in a GitHub issue. Similarly, snarky comments and flippant characterizations of others' perspectives are not constructive, and are not going to drive towards any desired outcome.

Spaces vs. tabs is a perpetually contentious topic with passionate proponents on both sides. It's a binary decision that necessitated picking one or the other as the default, and there were inevitably going to be drawbacks and one unhappy camp regardless of which was selected.

That default was selected long ago, but the associated tooling (rustfmt) supports both to allow users/teams to make their own choice based on what works best for them.

It's been stated previously, and subsequently reiterated, that the default isn't going to change, not unless sufficiently compelling new information is shared. Activities like adding duplicative comments, arguing with others, etc. only adds noise and makes it more difficult for individuals to determine which elements have already been discussed, and whether there is anything new they could add. That in turn has a mildly detrimental effect on the likelihood of achieving any sort of change.

It's well understood that there are certain style aspects people will be unhappy with, but this really isn't the proper forum for complaints nor repeating things ad nauseum. I'd encourage folks to direct that sort of commentary to other forums like Reddit, Twitter, etc. so that we can try to keep things more streamlined here to make it easier for others to potentially share new information.