MarkdownElementBuilder replaces only first child when builder returns a widget for inline elements

[Jess-Gabia]

Describe the bug

When a custom MarkdownElementBuilder is registered for an inline tag (e.g. a) and visitElementAfterWithContext returns a non-null widget, the builder only replaces current.children[0] instead of clearing all children. If the element has multiple children (e.g. link text containing delimiter characters like _ or *), the remaining children are still appended to the parent, causing duplicate text rendering.

To Reproduce

1. Register a custom builder for the a tag
2. Send a message containing a link whose text includes a delimiter character, e.g. [_hello world](https://example.com)
3. The markdown parser splits the link text into multiple children: [Text("_"), Text("hello world")]
4. The builder widget replaces only children[0], so Text("hello world") is also appended to the parent
5. Result: "hello world" appears twice

Expected behavior

When visitElementAfterWithContext returns a non-null widget, all existing children should be replaced by that widget — not just children[0].

Suggested fix

In builder.dart, change:

if (current.children.isEmpty) {
  current.children.add(child);
} else {
  current.children[0] = child;
}

to:

current.children
  ..clear()
  ..add(child);

[amungi]

This bug should be fixed on a high priority. The suggested fix is correct.

In our project, we are using the flutter_markdown_plus package, and we had to do a dependency override and use a patched version of this package with the exact fix mentioned in this issue, and the fix works fine.

[amungi]

@gazreese - this fix really needs to go into the package !

[gazreese]

I'm on the case @amungi

[gazreese]

Fixed in #136 and published to pub.dev as v1.0.9 🎉

The inline builder now replaces all of an element's children with the returned widget (matching the block-element path), so link text split on a _/* delimiter no longer renders twice. Covered by two new regression tests in test/custom_syntax_test.dart (verified failing before the fix, passing after).

Thanks @Jess-Gabia for the clear report and pinpointing the fix, and @amungi for confirming it in production — you can drop the dependency override once you're on 1.0.9. 🙏

[amungi]

Thanks a lot, @gazreese !