Coder Social home page Coder Social logo

Comments (6)

jgm avatar jgm commented on June 21, 2024

Yes, that should count as a lazy continuation.

from commonmark-hs.

jgm avatar jgm commented on June 21, 2024

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!

from commonmark-hs.

jgm avatar jgm commented on June 21, 2024

The disanalogy is actually in blockFinalize.
I wonder if that's the clue.

from commonmark-hs.

jgm avatar jgm commented on June 21, 2024

Evidence for this: if you change blockFinalize for footnote to defaultFinalizer, then the lazy line appears in a regular paragraph.

from commonmark-hs.

jgm avatar jgm commented on June 21, 2024

OK, I think I understand now what is happening.

In processLine, we close unmatched blocks
https://github.com/jgm/commonmark-hs/blob/master/commonmark/src/Commonmark/Blocks.hs#L138-L147
and in this case that would mean we close the footnote when we hit the unindented line. At this point the note's paragraph just contains "bar".

Laziness is handled at
https://github.com/jgm/commonmark-hs/blob/master/commonmark/src/Commonmark/Blocks.hs#L154-L159
Essentially, when we hit a lazy continuation, we simply add the closed blocks back to the node stack and proceed as before.

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 lookupReference is set up to prefer the first entry in case of duplicates, so we get the defective one.

from commonmark-hs.

jgm avatar jgm commented on June 21, 2024

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.

from commonmark-hs.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.