Question: 1.5 - Block that contains block customization

[joshbruce]

Been looking through the documentation and implementations. Might be overcomplicating matters or missing something obvious (seems harder than I thought it would be given limited past experience), first time doing block element customization, not sure of a more appropriate place to ask.

Question

Think the hiccup is: How do I pass a string back to the CommonMark for processing and capture the return for that block, but not the whole document??

After making the abbreviation customization, I decided to see if I could do the same with an accordion.

|++
|+ ## Heading
Markdown content
+|
+accordion-container-id+|

I'm thinking something that extends Document might be the way to go??

I'm thinking I need two parsers.

// start the outside
class AccordionBlockParser implements BlockParserInterface {}

// start each accordion
class AccordionParser  implements BlockParserInterface {}

At that point the initial bit is grabbing the content between:

|++
...
+accordion-container-id+|

Using the AccordionBlockParser; passing the content back to CommonMark, which will then hit the first accordion and call the AccordionParser.

The AccordionParser would build the header element, grab the content between:

|+
...
+|

and pass the lines in-between back to CommonMark and capture the return as its own content.

I'm identifying an extension that does something like this. I'm also not seeing a block element (Blockquote, CodeBlock, etc.) that does it the way I need to in an extension.

And may be completely overlooking in the docs where it says: If you want CommonMark to process a string and give you the result, do this.

ps. I would like to be able to process the individual accordions without wrapping. I think I know a way to do it - but if you think it's absolutely not possible, please do let me know.

[colinodell]

This type of block-within-block is a bit convoluted in 1.x but makes more sense in the upcoming 2.x release (still ~2 months away from release)

In a nutshell, your outer block parser should not be responsible for passing the inner content too. Rather, it should only parse the initial lines and characters that make up that first outer part. There are some methods on the block class in 1.x which control whether a block and any inner blocks might continue into other lines (this was extracted into BlockContinuationParsers in 2.x because the 1.x approach mixed two very different responsibilities in one class)

Take a closer look at ListBlock, particularly:

• matchesNextLine(): Helps determine if the block and any inner blocks might span additional lines
• canContain(): Determines if a potential inner block can be added to an outer one
• finalize(): called once the outer block is done being parsed

When you do have an open/unfinalized outer block, it'll be considered the "container" for any inner blocks that are found on subsequent lines. So it's really just a matter of making sure the engine keeps that container open so new blocks go into it. Take a look at how other blocks which contain blocks behave and what those different functions return.

Like I said, it's a bit messy in 1.x but much cleaner and more logical in 2.x.

I hope that at least gives you a good starting point. Apologies in advance for not providing super clear guidance or code examples as I'm on my mobile phone 🙃 But I hope that at least gives you some hints to move forward in the right direction! Feel free to follow up with any further questions I can help with.

[joshbruce]

Thanks! I think I get it.

1. The parsers (and cursor) go line-for-line; sorry if a silly question, not my habit to extend Markdown. lol
2. "Processing" the element may be just sending back an opening tag - then not finalizing the "container" until reaching the end of the block.
3. Having the id for the accordion might be doubly difficult given it's part of the opening element, but won't be discovered until the end.

Is the same instance of my Block class used at least until finalized??

(Still actively following rabbit-holes and trying not to go down known dead-ends.)

ps. Thanks for answering so quickly and from your phone. Might go ahead and run an experimental lap around [latest] - it definitely makes more sense to me (as I continue to forget to switch tags - lol - and find things I can't use).

[joshbruce]

Very helpful indeed: https://github.com/8fold/commonmark-accordions

Thank you again!