[Question] Syntax re-arrangement #178

New Issue

claunia · 2026-01-29T14:29:32Z

claunia commented

2026-01-29 14:29:32 +00:00

Originally created by @tthiery on GitHub (Jan 2, 2018).

I stumble over an exception in the following process:

Parse a markdown document
The following example:

**#1** This is the most important thing *ever*.

**#2** For sure not. `Coding` is more important

Analyze the syntax tree for certain patterns (e.g. first inline of paragraph is bold => Foo.Name = "#2")
Re-Align some syntax elements (e.g. restructure remaining paragraph inlines into new InlineContainer)
Normalize the re-aligned content of the paragraph (e.g. remaining text or whatever => Foo.Text = "For sure not. .....")

I had the expectation that I can re-arrange the syntax in step (3) without any issues. Similar what I would do with Newtonsoft.Json or System.Xml.Linq.

Actually the ContainerInline.AppendChild has explicit guard preventing adding a child which already has a parent.

Is there a reason for this behavior? Is there something we can do here (Cloning? Removing Guards? New Syntax concept? Alternatively, are there utilities to help me utilizing the Span information to retrieve the original text?).

Originally created by @tthiery on GitHub (Jan 2, 2018). I stumble over an exception in the following process: 1. Parse a markdown document The following example: ````markdown **#1** This is the most important thing *ever*. **#2** For sure not. `Coding` is more important ```` 2. Analyze the syntax tree for certain patterns (e.g. first inline of paragraph is bold => Foo.Name = "#2") 3. Re-Align some syntax elements (e.g. restructure remaining paragraph inlines into new InlineContainer) 4. Normalize the re-aligned content of the paragraph (e.g. remaining text or whatever => Foo.Text = "For sure not. .....") I had the **expectation** that I can re-arrange the syntax in step (3) without any issues. Similar what I would do with `Newtonsoft.Json` or `System.Xml.Linq`. **Actually** the `ContainerInline.AppendChild` has explicit guard preventing adding a child which already has a parent. Is there a reason for this behavior? Is there something we can do here (Cloning? Removing Guards? New Syntax concept? Alternatively, are there utilities to help me utilizing the Span information to retrieve the original text?).

claunia added the question PR Welcome! labels 2026-01-29 14:29:32 +00:00

claunia commented

2026-01-29 14:29:33 +00:00

@tthiery commented on GitHub (Jan 2, 2018):

I found a workaround by removing the child from the original tree. Kind of works for now (for me).

Is there any improvements vision on that part of the API? Working with the syntax tree is something quite interesting for me ;)

@tthiery commented on GitHub (Jan 2, 2018): I found a workaround by removing the child from the original tree. Kind of works for now (for me). Is there any improvements vision on that part of the API? Working with the syntax tree is something quite interesting for me ;)

claunia commented

2026-01-29 14:29:34 +00:00

@xoofx commented on GitHub (Jan 3, 2018):

Is there a reason for this behavior? Is there something we can do here (Cloning? Removing Guards? New Syntax concept? Alternatively, are there utilities to help me utilizing the Span information to retrieve the original text?).

Yes. It is mainly to make sure that a node cannot be attached multiple times (or even recursively) and also to force an explicit management where you can't move accidentally a node by adding it as a new child of another parent (and implicitly removing it from the previous parent). I had quite a few bugs directly related to this when building markdig and I was happy to have these safeguards.

So the access pattern as you figured out is to remove the node, and add it to somewhere else. To mitigate usage, adding a method like Move that does a remove and an append would be fine, PR welcome if you want!

@xoofx commented on GitHub (Jan 3, 2018): > Is there a reason for this behavior? Is there something we can do here (Cloning? Removing Guards? New Syntax concept? Alternatively, are there utilities to help me utilizing the Span information to retrieve the original text?). Yes. It is mainly to make sure that a node cannot be attached multiple times (or even recursively) and also to force an explicit management where you can't move accidentally a node by adding it as a new child of another parent (and implicitly removing it from the previous parent). I had quite a few bugs directly related to this when building markdig and I was happy to have these safeguards. So the access pattern as you figured out is to remove the node, and add it to somewhere else. To mitigate usage, adding a method like `Move` that does a remove and an append would be fine, PR welcome if you want!

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/markdig#178