Unexpected changes in continuation behavior between 0.8.0 and 1.0.0 release?

[ignatiusreza]

Initial checklist

• [X] I read the support docs
• [X] I read the contributing guide
• [X] I agree to follow the code of conduct
• [X] I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions

mdast-util-from-markdown@1.0.0 (via remark-parse@10.0.0)

Link to runnable example

https://codesandbox.io/s/rough-silence-cu56j?file=/src/grid/syntax.js

Steps to reproduce

In the linked codesandbox above, compare the rendered output (and console log) between remark-parse is locked at v9.0.0 vs v10.0.0

• in v9.0.0 (mdast-util-from-markdown@^0.8.0): continuation correctly trigger exit when nok was returned, as seen in the console.log output of:

  #### START 
  onGridStart 
  shouldContinue?  ok 
  shouldContinue?  ok 
  shouldContinue?  nok 
  onGridExit 
  onGridStart 
  shouldContinue?  ok 
  shouldContinue?  ok 
  shouldContinue?  nok 
  onGridExit 

• in v10.0.0 (mdast-util-from-markdown@^1.0.0): a 2nd "onGridStart" somehow gets triggered before the first continuation exits, leading to imbalance enter-exit effects pair:

  onGridStart 
  shouldContinue?  ok 
  shouldContinue?  nok 
  onGridStart 
  onGridExit 
  onGridStart 
  shouldContinue?  ok 
  shouldContinue?  nok 
  onGridExit

Expected behavior

a 2nd enter should not be triggered before the 1st exited

Actual behavior

a 2nd enter is triggered triggered before the 1st exited

Runtime

No response

Package manager

No response

OS

No response

Build and bundle tools

No response

[wooorm]

did you run the code in debug mode? https://github.com/micromark/micromark#size--debug Any errors there?

[wooorm]

Note that for containers, micromark does “attempts”, which could be thrown away. So it could be that the start is called again, but the result ignored.

Is there an actual problem you’re noticing, or is it unexpected console calls?

[ignatiusreza]

did you run the code in debug mode?

I just did, and I didn't see any errors

Is there an actual problem you’re noticing, or is it unexpected console calls?

we process the mdast further with some custom renderer, type: "grid" is treated as a custom element.. and the rendered output changed between the release.. with the input of

%col
  left
%col
  right
foo

the eventual rendered output becomes:

• in v9.0.0 (mdast-util-from-markdown@^0.8.0):

  <grid>
  <p>left</p>
  </grid>
  <grid>
  <p>right</p>
  </grid>
  <p>foo</p>

• in v10.0.0 (mdast-util-from-markdown@^1.0.0):

  <grid>
  <p>left</p>
  </grid>
  <grid>
  <p>right\nfoo</p>
  </grid>

which I assumed was caused by the imbalance event.. but, maybe there're other changes which can cause it?

[wooorm]

No, that’s something else. There was issue with laziness/interrupting, which is exactly that line you describe. The previous behavior didn’t work so I had to make it explicit.

Here is an example of a blockquote with a lazy line:

> a
b

b is part of the paragraph, which is part of the blockquote. All containers in plain markdown (block quotes, list items) support this.

If you don’t want this behavior you can check on the first character after a newline, whether the line is lazy or not:

• https://github.com/micromark/micromark-extension-mdx-expression/commit/2d8563ec26913a3dfb4ea5692c9ea4c994c3c4ba
• https://github.com/micromark/micromark-extension-math/commit/5a13899d393af162e8908831024e00d30a03220c

[ignatiusreza]

i see, i didn't know that lazy line is a thing in markdown.. i tested that the same change in behavior is observable in other construct as well, e.g. list..

given that the updated behavior is considered a bugfix, i'll close this ticket..

[github-actions[bot]]

Hi! This was closed. Team: If this was fixed, please add phase/solved. Otherwise, please add one of the no/* labels.

[github-actions[bot]]

Hi team! Could you describe why this has been marked as wontfix?

Thanks, — bb