Set range end to Paragraph if returned early because of footnote definition#831
Conversation
|
No problem, version 0.9.5 has just been released and 0.9.4 is yanked. |
|
Thanks a lot! |
|
0.9.6 just released updating Cargo.lock and 0.9.5 yanked to fix #833. |
|
Thanks! :) |
|
No need of 'frontporting' to 0.10, this was already implemented as the new footnotes in #654. |
|
Apparently not when looking at https://github.com/raphlinus/pulldown-cmark/pull/654/files#diff-243abda520cdeea7f9b927714d874cf1ffa167c126d84089cef20d697e97532dR143. This still needs to be fixed. |
|
It is fixed in the new footnotes type, fully compatible with GitHub, but it does not in the old type. Probably convenient to have the same behavior than 0.9.6... |
|
It is not based on what is in https://github.com/raphlinus/pulldown-cmark/blob/master/specs/footnotes.txt. You can't do (as is, you won't have two footnote definitions): Lorem ipsum.[^a] [^missing]
[^a]: def1
[^missing]: def2 |
|
OK, I had only checked the spec test with two consecutive footnotes without an empty line between them. So this could be applied to the two types of footnotes then. Thanks! |
|
So I'll try to backport my PR as mentioned in the coming days (might be tricky with me needing to prep for FOSDEM) or next week. :) |
My deepest apologies, I didn't notice but the end range was not filled and it panicked when running rustdoc on the code I used for the test. I fixed it and added a regression test to ensure the range is always filled as expected.
Can you yank the
0.9.4version and release the0.9.5please? Again, I'm very sorry for not noticing the bug earlier on.