Make indentation (spaces vs tabs, tab width) configurable

[0x7CFE]

The code in the if let block was indented by tabs, but "replace with match" suggestion mistakenly indents match arms with spaces.

[matklad]

Yeah, we unfortunately hard-code four space indentation for now.

[Keavon]

This also happens for "Fill match arms".

[0x7CFE]

Out of curiosity, can https://github.com/udoprog/genco be used to generate the code on behalf of RA? It is reportedly whitespace aware and configurable.

[Timmmm]

This is kind of infuriating. What is involved in fixing it? Can I just make the 4 configurable here and here and add some kind of flag to tell it to use tabs instead?

[matklad]

Can I just make the 4 configurable here and here and add some kind of flag to tell it to use tabs instead?

Probably not, editing code should be agnostic about indentation configuration. I think the proper way to fix this is to remove manual indentation entirely in favor of generic indenter: #4182

[flodiebold]

Just as a note, the fact that this is marked unactionable doesn't mean we don't want to fix it, or that no-one is allowed to work on it. It just means we don't see a direct way of making progress on it, because it depends on another issue.

If you care about this and think there is a more simple fix for this, feel free to implement it and make a PR. It just needs to work and be maintainable; it should not make it harder to write assists.

[tehsunnliu]

Hi, any hint where this is hardcoded? and what is causing the problem?

[bjorn3]

Every snippet literally contains the precise amount of spaces to insert. Changing the indentation currently requires updating all snippets AFAIK. Fixing this issue will require some way to either replace the fixed indentation of the snippets or be able to write the snippets without fixed indentation I think.

[WilliamVenner]

hard_tabs and tab_spaces could be read from rustfmt.toml

[bjorn3]

It should probably be read from the editor configuration rather than rustfmt.toml.

[deanfra]

Taking a hint from the above comment, I added my preferred tab_spaces setting to rustfmt.toml and Rust Analyzer seems to abide by it in VS Code. Not sure if that's expected behaviour but I'm happy for now!

[Barugon]

This should be passed to rustfmt on the command line with --config tab_spaces=[tab-size value from vscode] as well as any other applicable options.

[Dessix]

While formatting via rustfmt works with tab_spaces=#, the remaining focuses of this issue appear to be that generated code and snippets are hardcoded to 4 spaces.

Items remaining to solve before this can be closed:

• [ ] 1: as @bjorn3 mentioned, snippets require a means of whitespace placement that is not of a fixed width
  • Can this be addressed directly? Has this state of affairs changed since 2021?
  • Can this be worked around, perhaps by running rustfmt on the snippet after emplacement?
• [ ] 2: Generated code assumes a hardcoded 4-spaced indentation and default rustfmt formatting
  • Can we simply invoke rustfmt on the selection within the current workspace context? Code generation lacks an interactive parameterization step, so doing this here may be easier than with the static snippets in (1).

Lastly, as tehsunnliu asked, do we know where all of these are hardcoded, such that we can build and evaluate a plan for fixing it?

[Timmmm]

I already linked where it is hardcoded. See my comment above and @matklad 's reply - which to be honest I didn't really understand.

[Veykril]

Can this be addressed directly? Has this state of affairs changed since 2021?

It has not no

Can this be worked around, perhaps by running rustfmt on the snippet after emplacement?

In the general case, not really no. The text some assists create aren't really single entities that can be formatted by rustfmt (hence the need for our own syntax formatter https://github.com/rust-lang/rust-analyzer/issues/1665)

[codemaster138]

Taking a hint from the above comment, I added my preferred tab_spaces setting to rustfmt.toml and Rust Analyzer seems to abide by it in VS Code. Not sure if that's expected behaviour but I'm happy for now!

Ever since I updated to rustc 1.63.0 yesterday, this doesn't work anymore

[sslime336]

Here is my config in VSCode, edited in settings.json

"[rust]": {
  "editor.defaultFormatter": "rust-lang.rust-analyzer",
  "editor.tabSize": 2
},
"rust-analyzer.rustfmt.extraArgs": ["--config", "tab_spaces=2"],

My rust version is 1.67.0-nightly (73c9eaf21 2022-11-07) But when I start a new proj using cargo new xxx, it is still 4 spaces by default... Well, I'm going to force myself to adapt 4 spaces width in order to not change the default setting every time I create a new proj :P

[lnicola]

@sslime336 you can configure it just once, but it might annoy people if you ever try to contribute to projects without a rustfmt.toml.

[lnicola]

Don't have such fine-grained control, but Code has an editor.stickyTabStops option which snaps the cursor to tab stops, even when you're using spaces for indentation. I don't think you can configure it to show two instead of four spaces, though.

[sslime336]

You are right. My muscle memory makes me didn't even notice that I've pressed the formatting buttons. Sorry. 😂

Btw, thanks for your reminding :)

[Timoyoungster]

Is anyone working on a solution right now?

[jacobaagaardbennike]

@Timoyoungster there is a sollution. It's to add a rustfmt.toml file to your project with the following line:

tab_spaces=2

Then if you have the following in your VSC settings file:

 "[rust]": {
    "editor.defaultFormatter": "rust-lang.rust-analyzer",
    "editor.formatOnSave": true
  },

It will work for not only you, but for anyone working on your project.

[Timoyoungster]

@Timoyoungster there is a sollution. It's to add a rustfmt.toml file to your project with the following line:

Thank you, I will try that for now.