-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Migrate # -> ## in doc headers. #16082
Conversation
I think it's better to tweak the Rustdoc CSS to make |
We should be at liberty to declare that here, |
If this is just changing all headers in rustdocs to '##', leaving no '#', then I prefer to change rustdoc to make this work as expected. Old rustdoc actually silently converted '#' to '##' before translating to markdown if I recall. |
I'm not a fan of changing Markdown's semantics just because. |
Also, these are never top-level headers. They're secondary headers. It doesn't make sense to mark up secondary headings as primary headings and then render them as secondary headings. |
@steveklabnik The reasoning for using |
Gotcha. Then we're not really doing markdown, we're doing our own kinda-markdown format. Which is a decision we can make, but it should be made explicitly. |
Well, we already are using a bunch of markdown extensions (appears to be equivalent to GitHub-flavored Markdown + superscripts), so we've already diverged from straight markdown anyway. |
Extensions are one thing, and GH flavored markdown is basically markdown, since Gruber's governance of markdown is terrible. Changing the way headings work is a pretty significant divergence. |
Longterm, do we plan to stick to Hoedown, or would we like to migrate to a pure Rust solution for markdown handling? Hoedown doesn't strike me as particularly configurable outside of the ~10 flags they offer (hardcoded special characters as inline string literals is a notable pattern in their source). Maybe they offer some nice plugin utilities, but their documentation is very weak. And of course C-bindings are always a higher security risk that native Rust. |
This PR is super out of date, so I'm just going to close it. |
…e-5, r=Veykril internal: Migrate assists to the structured snippet API, part 5 Continuing from rust-lang#15874 Migrates the following assists: - `extract_variable` - `generate_function` - `replace_is_some_with_if_let_some` - `replace_is_ok_with_if_let_ok`
…e-6, r=DropDemBits internal: Migrate assists to the structured snippet API, part 6/7 Continuing from rust-lang#16082 Migrates the following assists: - `extract_function` - `generate_getter_or_setter` - `generate_impl` - `generate_new` - `replace_derive_with_manual_impl` Would've been the final PR in the structured snippet migration series, but I didn't notice that `generate_trait_from_impl` started to use `{insert,replace}_snippet` when I first started the migration 😅. This appears to be a pretty self-contained change, so I'll leave that for a separate future PR. This also removes the last usages of `render_snippet`, which was a follow up goal of rust-lang#11638. 🎉
I busted out some
git grep | xargs sed
and fixed this. I've reviewed the diff, and it should be good. Please double check me, though!Fixes #15499