-
-
Notifications
You must be signed in to change notification settings - Fork 31
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
[fuzz result] unindented lines after footnote def are silently eaten #126
Comments
Fixes jgm#126 This change brings it into alignment with GitHub, [markdown-it](https://markdown-it.github.io/#md3=%7B%22source%22%3A%22%5B%5Efoo%5D%3Abar%5Cnbaz%5Cn%5Cn%20%20%20%20quux%5Cnarst%5Cn%20%20%20%20qwfp%5Cn%5Cn%5B%5Efoo%5D%22%2C%22defaults%22%3A%7B%22html%22%3Afalse%2C%22xhtmlOut%22%3Afalse%2C%22breaks%22%3Afalse%2C%22langPrefix%22%3A%22language-%22%2C%22linkify%22%3Atrue%2C%22typographer%22%3Atrue%2C%22_highlight%22%3Atrue%2C%22_strict%22%3Afalse%2C%22_view%22%3A%22html%22%7D%7D), and hugo/goldmark.
Yes, that should count as a lazy continuation. |
I don't understand why the lazy line isn't being handled properly. Look at blockQuoteSpec for an analogy. This one should behave the same! |
The disanalogy is actually in blockFinalize. |
Evidence for this: if you change blockFinalize for footnote to defaultFinalizer, then the lazy line appears in a regular paragraph. |
OK, I think I understand now what is happening. In processLine, we close unmatched blocks Laziness is handled at Normally, this works fine! But in the case of footnoteBlockSpec, it doesn't, because in this case blockFinalize has a side effect -- it updates the reference map with the note contents. In fact, the reference map will be updated again after the re-added footnote is closed again (this time with "baz"). So at this point there will be two entries with key "foo." But |
Solution? I'm not sure. It does seem non-ideal that in our treatment of lazy lines, we end up calling blockFinalize twice (or even more) for the same block, even though in most cases this is harmless. So, perhaps, instead of closing the blocks at line 138, we should wait until we actually detect a new block -- at that point we'd need to close the unmatched ones. If no new block is detected, then, unless we had a lazy line, we could close unmatched blocks, but if we had a lazy line, we'd still have the unmatched blocks open and wouldn't need to re-add them. This might even improve performance a bit when there are lots of lazy lines. |
Consider this markdown:
It's debatable whether
baz
should be part of the footnote or not, but it should certainly appear in the output somewhere. Right now, commonmark-extensions discards it.In GitHub, it renders like this:
1
Footnotes
bar
baz ↩
The text was updated successfully, but these errors were encountered: