-
Notifications
You must be signed in to change notification settings - Fork 232
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
End footnote definition with one blank line. #21
Conversation
According to the linked issue, a footnote definition should end with a blank line. This is similar to the rule for lists, which end with two blank lines. The code previously required two blank lines in both cases, this patch changes it to just one for footnote definitions. Fixes issue 20.
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
According to the linked issue, a footnote definition should end with a blank line. This is similar to the rule for lists, which end with two blank lines. The code previously required two blank lines in both cases, this patch changes it to just one for footnote definitions. Fixes issue 20.
CLAs look good, thanks! |
Fixes issue #20, see more discussion there. |
If this is going to be merged, |
I need this to be merged. Do you know when this we'll done? |
In order to merge this, I need more confidence that it's compliant with the spec, which I currently don't have. Otherwise, if you need non-spec-compliant behavior for compatibility, then divergence from the spec needs to be a flag that gets set. |
Seems like it is. |
Ah, ok. I'll play a bit with whether this PR actually does the right thing, and if so I'll merge it relatively soon. |
Great, thanks a lot! PS: pulldown-cmark is now the markdown parser used in rustdoc (congrats!). |
I don't think this shows anything in favor or against. That tool has no support for footnotes so it interprets It appears as though the footnote spec in this repository treats them more like link references than list items. This is probably not right because link references can only contain a small number of specific items, while a footnote seems like it should be a container block. I also just left a comment at #20 (comment). |
…veklabnik Add support for image, rules and footnotes Part of #40912. r? @rust-lang/docs PS: the footnotes are waiting for pulldown-cmark/pulldown-cmark#21 to be merged to be fully working.
Based on discussion in https://internals.rust-lang.org/t/what-to-do-about-pulldown-and-commonmark/5115 I am inclined to merge this. Any final comments? Thanks to everybody who's weighed in here, and sorry for not taking action on it sooner. |
Finally! \o/ |
Since this would be a "breaking change" anyway, may I suggest breaking a little further and disallowing blocks inside footnote definition (if it is easy enough)? For example:
Should produce either:
or
So that this would just be a baseline implementation of footnotes. And further changes based on whichever spec that we choose to adopt will not "break" much. Since pulldown-cmark is now being used by rustdoc, implementation-specific features should be kept as thin as possible, in my opinion. |
Thanks! |
I'm merging this because it seems like an overall improvement. The suggestion by critiqjo seems valid, but I haven't had time to research it in detail. I'd happily take a patch for it as a further refinement, as long as there's evidence it won't cause regressions, etc. This is released as v0.0.15. |
This broke several footnotes spec tests:
It's important to pass all these since they are basically the only definition of this particular footnote spec. I haven't looked at them, but I am guessing the tests need to be updated. |
The footnote change (issue #21) broke some tests. In some cases (just the number of newlines) the tests needed to be updated, but in others (allowing complex block structure) the code needed to be fixed.
According to the linked issue, a footnote definition should end with a
blank line. This is similar to the rule for lists, which end with two
blank lines. The code previously required two blank lines in both
cases, this patch changes it to just one for footnote definitions.
Fixes issue 20.