[PR #58] [MERGED] Fixes issue when using colon (among others) on lines with abbreviations #798

New Issue

claunia · 2026-01-29T14:45:39Z

claunia commented

2026-01-29 14:45:39 +00:00

📋 Pull Request Information

Original PR: https://github.com/xoofx/markdig/pull/58
Author: @christophano
Created: 9/15/2016
Status: ✅ Merged
Merged: 9/18/2016
Merged by: @xoofx

Base: master ← Head: bugfix/abbreviation-existing-container

📝 Commits (1)

1b92311 Fixes issue when using colon (among others) on lines with abbreviations

📊 Changes

2 files changed (+16 additions, -8 deletions)

View changed files

📝 src/Markdig/Extensions/Abbreviations/AbbreviationParser.cs (+11 -7)
📝 src/Markdig/Parsers/InlineProcessor.cs (+5 -1)

📄 Description

I discovered a very strange issue when using abbreviations inline after a potential delimiter (in my case, a colon).
The code would throw an ArgumentException from line 54 of ContainerInline.cs.
Example:

Some abbreviations: HTML, WWW
*[HTML]: Hypertext Markup Language
*[WWW]: World Wide Web

This is due to the processor storing the first part of the content in a LiteralInline while it tries to validate the character as a valid delimiter. When this fails it returns and continues with the rest of the inline, including the first section. This means that when the AbbreviationParser finds a valid abbreviation during the post match, the LiteralInline already has a parent, which throws the exception.

The solution involves using the existing LiteralInline parent as the container (if it exists) instead of creating a new ContainerInline and checking that the parent is null before the call to ContainerInline.AppendChild.
There is also a check in InlineProcessor, when adding an inline without a parent as a child of the last container that this is not already the last container. This would mean at some point the parent is not being assigned when it ought to have been (I haven't found this yet though), but the check is poss

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/xoofx/markdig/pull/58 **Author:** [@christophano](https://github.com/christophano) **Created:** 9/15/2016 **Status:** ✅ Merged **Merged:** 9/18/2016 **Merged by:** [@xoofx](https://github.com/xoofx) **Base:** `master` ← **Head:** `bugfix/abbreviation-existing-container` --- ### 📝 Commits (1) - [`1b92311`](https://github.com/xoofx/markdig/commit/1b92311aebac8d141b0f7a65a12fba077a557514) Fixes issue when using colon (among others) on lines with abbreviations ### 📊 Changes **2 files changed** (+16 additions, -8 deletions) <details> <summary>View changed files</summary> 📝 `src/Markdig/Extensions/Abbreviations/AbbreviationParser.cs` (+11 -7) 📝 `src/Markdig/Parsers/InlineProcessor.cs` (+5 -1) </details> ### 📄 Description I discovered a very strange issue when using abbreviations inline after a _potential_ delimiter (in my case, a colon). The code would throw an `ArgumentException` from line 54 of `ContainerInline.cs`. Example: ``` md Some abbreviations: HTML, WWW *[HTML]: Hypertext Markup Language *[WWW]: World Wide Web ``` This is due to the processor storing the first part of the content in a `LiteralInline` while it tries to validate the character as a valid delimiter. When this fails it returns and continues with the rest of the inline, including the first section. This means that when the `AbbreviationParser` finds a valid abbreviation during the post match, the `LiteralInline` already has a parent, which throws the exception. The solution involves using the existing `LiteralInline` parent as the container (if it exists) instead of creating a new `ContainerInline` and checking that the parent is null before the call to `ContainerInline.AppendChild`. There is also a check in `InlineProcessor`, when adding an inline without a parent as a child of the last container that this is not already the last container. This would mean at some point the parent is not being assigned when it ought to have been (I haven't found this yet though), but the check is poss --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

claunia added the pull-request label 2026-01-29 14:45:39 +00:00

claunia closed this issue

2026-01-29 14:45:41 +00:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/markdig#798