-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Remove weird handling of ## in code examples #118825
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
Remove weird handling of ## in code examples #118825
Conversation
Let's start a crater run then. @craterbot run mode=build-and-test +cargoflags=--doc |
🚨 Error: failed to parse the command 🆘 If you have any trouble with Crater please ping |
Seems like what I wanted to do is actually not possible... @craterbot run mode=build-and-test |
🚨 Error: missing start toolchain 🆘 If you have any trouble with Crater please ping |
@craterbot run mode=build-and-test |
🚨 Error: missing start toolchain 🆘 If you have any trouble with Crater please ping |
Ah, maybe I need to have run @bors try |
This comment has been minimized.
This comment has been minimized.
… r=<try> Remove weird handling of ## in code examples As mentioned in rust-lang#118711, the handling of `##` in code blocks in code examples is very surprising. Let's see if crates are using it with a crater run. r? `@notriddle`
… r=<try> Remove weird handling of ## in code examples As mentioned in rust-lang#118711, the handling of `##` in code blocks in code examples is very surprising. Let's see if crates are using it with a crater run. r? `@notriddle`
☀️ Try build successful - checks-actions |
@craterbot run mode=build-and-test |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
Seems like there is no change as far as I can see? |
Might be worth starting an FCP then since it's a breaking change. @rfcbot fcp merge |
Team member @GuillaumeGomez has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
I see a broken doctest on the second "test failed (unknown)" I looked at: https://crater-reports.s3.amazonaws.com/pr-118825/try%235e4273472e1b2f223618a9b3def795f6224f241d/reg/ctflag-0.1.2/log.txt |
Good catch! So we can't revert it like this apparently... |
Hold on, is the change to always render Here's what I expect:
|
I would prefer to avoid adding more indentation-based logic. This kind of thing makes it hard to tell if something is considered indented or not. https://talk.commonmark.org/t/unsure-how-the-0-29-spec-handles-this-list-indentation/3326 |
This isn't about list indentation, though, this is about codeblock indentation; which tends to just follow the indentation of the opening backticks. I think that's an okay heuristic. Either way, I don't see this PR as an improvement; it seems to not be fixing the problem brought up in #118711 but instead trying a new direction and I can't see the reasoning behind that. |
Then I misunderstood what I thought the problem was: I thought the issue was that we were replacing |
I thought that was a way of doing an escape code |
An escape for |
Right. I think that's an intentional design to escape for |
What seems like a bug to me is that we do this for any |
Oh! So But yeah we shouldn't be doing this for every I think someone needs to properly write down what the current behavior is and what it would be in an ideal world, because so far nobody has given a full rundown of the situation. |
I also found the issue where this was originally added: |
Had a discussion with the author and they did mention that this pr is headed nowhere so the best option is to close it. |
As mentioned in #118711, the handling of
##
in code blocks in code examples is very surprising. Let's see if crates are using it with a crater run.description
Currently, if you have two
#
characters following each other, the first one will be stripped. So this code:is rendered as:
This PR removes this behaviour and won't strip the first
#
item so the previous code will be rendered:Motivation
It looks more like a bug rather than a feature as it is a very unexpected behaviour. This PR intends to remove it. As seen in the crater run below, it seems no published crate relies on it either.
r? @notriddle