format hidden code

[ezpuzz]

This will allow hidden code to be formatted the same as not hidden.

I did not implement any configuration options so let me know if you think this opinionated default is alright.

I'm going to use this on the https://github.com/amethyst/amethyst docs.

[ezpuzz]

there's a bug with # #[derive(Debug)] attr statements, fixing.

[hukkin]

Hi there, thanks for the PR, always nice to have more people participate 😄

A few things I'd like to discuss before reviewing.

To my knowledge rustfmt doesn't give this treatment to doc comments. Maybe there is a reason for that, and if so that might be valuable for us to know?

So the current behavior (i.e. no formatting and # character indented) is closer to what rustfmt does to doc comments, and also what the examples e.g. on rust-lang.org show when it comes to whitespace usage before and after the # character. Would that then perhaps be the more expected/wanted default?

Could there be any disadvantages in doing this formatting? Any way it can introduce AST breaking changes? Perhaps it adds unwanted indentation to the visible code if the visible code is wrapped in a hidden function?

I'm a Rust n00b and not well-versed in community standards and best practices, so I'd also love to hear if other community members and potential users (so far only @lambda-fairy to my knowledge, haha) have thoughts on this.

[ezpuzz]

So the current behavior (i.e. no formatting and # character indented) is closer to what rustfmt does to doc comments, and also what the examples e.g. on rust-lang.org show when it comes to whitespace usage before and after the # character. Would that then perhaps be the more expected/wanted default?

I don't see the example you mention where the # is indented? The rustdoc comments specify hidden lines with /// # and align unhidden lines to the #. They are valid markdown if you remove the /// (including leading space) from the start of each line, so that is what I'm replicating here. The # should be the first character on the line in this case.

Could there be any disadvantages in doing this formatting? Any way it can introduce AST breaking changes? Perhaps it adds unwanted indentation to the visible code if the visible code is wrapped in a hidden function?

I don't believe there are any disadvantages. rustfmt would fail on invalid code and not change anything. internally in rustdoc test it is just stripping and replacing the # as well. The second point is interesting, there is an example on the link you posted where the unhidden code within an fn is at a lower indent than it would be if the code were all unhidden. That doesn't matter to me personally though, I don't even know if it would be visible in mdbook. When I copy from a doc the leading indentation is often incorrect or irrelevant. Also if it is visible it serves as a hint to the user about the snippets purpose to maintain document level indentation and means often the user would not need to reformat their code after copy-pasting.

[hukkin]

I don't see the example you mention where the # is indented?

Lol, sorry for this, you're completely right, don't know exactly what I was thinking... 😄

Ok so a question: Let's imagine there actually is an indented hidden line 😄 Which of the following three is the most "standard"?

1.

```rust
fn main() {
#   println!("Hello ");
    println!("World!");
}
```

2.

```rust
fn main() {
# println!("Hello ");
    println!("World!");
}
```

3.

```rust
fn main() {
    # println!("Hello ");
    println!("World!");
}
```

From what you wrote, I understand the third form is not even correct? If not then I definitely need to revert the last change I made to mdformat-rustfmt....

[hukkin]

Btw. this mdBook example does indent unhidden code in a hidden function, unlike the rustdoc example, so it seems both happen in the wild.

[ezpuzz]

I found a pretty bad bug I need to fix. I assumed that rustfmt would not collapse the special comments on to an existing line, but that's not always the case. I have a failing test.

[ezpuzz]

It would make the most sense to me that lines are only hidden if the very first character is an octothorpe. I think number 1 reads the nicest as the indent is consistent for actual statements.