[Documentation] Support for configure markdown characters #308

New Issue

claunia · 2026-01-29T14:33:28Z

claunia commented

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

Originally created by @RubenMateus on GitHub (Jul 10, 2019).

This is more kinda of question, and my question is if is there any way to configure what characters the markdown associates with html types.
For example: i have a string like "I am crazy" -> toHtml() ->

I am crazy

.
Like passing a dictionary of characters to replace for instead of the "regular" markdown

Originally created by @RubenMateus on GitHub (Jul 10, 2019). This is more kinda of question, and my question is if is there any way to configure what characters the markdown associates with html types. For example: i have a string like "I am *crazy*" -> toHtml() -> I am crazy. Like passing a dictionary of characters to replace for instead of the "regular" markdown

claunia added the question label 2026-01-29 14:33:28 +00:00

claunia closed this issue

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

claunia commented

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

@MihaZupan commented on GitHub (Jul 10, 2019):

By default Markdig will honor the Commonmark specification. Markdown is not the simplest of languages, it is far from a list of substitutions.

A lot of things are configurable, for example if you wanted to always treat * as bold and _ as italic, you can change the function that decides that in the actual renderer (EmphasisInlineRenderer).

See the following code for an example. Most of it is what happens if you use the static Markdown.ToHtml() directly.

string markdown = "I am *crazy*";

var builder = new MarkdownPipelineBuilder();

var pipeline = builder.Build();

MarkdownDocument document = Markdown.Parse(markdown, pipeline);

StringWriter writer = new StringWriter();
var renderer = new HtmlRenderer(writer);
pipeline.Setup(renderer);

// This is the actual change from the default
var emphasisRenderer = renderer.ObjectRenderers.Find<EmphasisInlineRenderer>();
emphasisRenderer.GetTag = emphasis => emphasis.DelimiterChar == '*' ? "strong" : "em";
// *bold* and _italic_ even with **double**
// <p><strong>bold</strong> and <em>italic</em> even with <strong>double</strong></p>

renderer.Render(document);
writer.Flush();

Console.WriteLine(writer.ToString());

If you wanted to use a different character to match headings, you can change that like

var headingParser = builder.BlockParsers.Find<HeadingBlockParser>();
headingParser.OpeningCharacters = new[] { '?' };
// "? Am I crazy" => "<h1>Am I crazy</h1>"

Some, but not all, things are configurable with simple one-liners, I can help you out with concrete examples.

@MihaZupan commented on GitHub (Jul 10, 2019): By default Markdig will honor the Commonmark specification. Markdown is not the simplest of languages, it is far from a list of substitutions. A lot of things are configurable, for example if you wanted to always treat `*` as bold and `_` as italic, you can change the function that decides that in the actual renderer (`EmphasisInlineRenderer`). See the following code for an example. Most of it is what happens if you use the static Markdown.ToHtml() directly. ```c# string markdown = "I am *crazy*"; var builder = new MarkdownPipelineBuilder(); var pipeline = builder.Build(); MarkdownDocument document = Markdown.Parse(markdown, pipeline); StringWriter writer = new StringWriter(); var renderer = new HtmlRenderer(writer); pipeline.Setup(renderer); // This is the actual change from the default var emphasisRenderer = renderer.ObjectRenderers.Find<EmphasisInlineRenderer>(); emphasisRenderer.GetTag = emphasis => emphasis.DelimiterChar == '*' ? "strong" : "em"; // *bold* and _italic_ even with **double** // bold and italic even with double renderer.Render(document); writer.Flush(); Console.WriteLine(writer.ToString()); ``` If you wanted to use a different character to match headings, you can change that like ```c# var headingParser = builder.BlockParsers.Find<HeadingBlockParser>(); headingParser.OpeningCharacters = new[] { '?' }; // "? Am I crazy" => "<h1>Am I crazy</h1>" ``` Some, but not all, things are configurable with simple one-liners, I can help you out with concrete examples.

claunia commented

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

@RubenMateus commented on GitHub (Jul 10, 2019):

Ok sounds like what i need is kinda doable, let me give you an example.

This is the input:

test *test* test
dsasd

^test
^test
^test
^test
ola

The output i want from this is:

<p>test <b>test</b> test<br>
dsasd</p>

<ul>
	<li>test</li>
	<li>test</li>
	<li>test</li>
	<li>test</li>
</ul>
<p>ola</p>

Is this even possible?
ps: thanks for the help

@RubenMateus commented on GitHub (Jul 10, 2019): Ok sounds like what i need is kinda doable, let me give you an example. This is the input: ``` test *test* test dsasd ^test ^test ^test ^test ola ``` The output i want from this is: ``` test test test dsasd <ul> <li>test</li> <li>test</li> <li>test</li> <li>test</li> </ul> ola ``` Is this even possible? ps: thanks for the help

claunia commented

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

@MihaZupan commented on GitHub (Jul 10, 2019):

For something like that you'd need to create a new ListItemParser, like

builder.BlockParsers.Find<ListBlockParser>().ItemParsers.Add(new CustomListItemParser());

class CustomListItemParser : UnorderedListItemParser
{
    public CustomListItemParser()
    {
        OpeningCharacters = new[] { '^' };
    }
}

but you'd still have to use spaces after ^ and add a new line before ola.

If you wanted the exact behavior you described, you'd have to write your own parser for lists.

@MihaZupan commented on GitHub (Jul 10, 2019): For something like that you'd need to create a new ListItemParser, like ```c# builder.BlockParsers.Find<ListBlockParser>().ItemParsers.Add(new CustomListItemParser()); class CustomListItemParser : UnorderedListItemParser { public CustomListItemParser() { OpeningCharacters = new[] { '^' }; } } ``` but you'd still have to use spaces after `^` and add a new line before `ola`. If you wanted the exact behavior you described, you'd have to write your own parser for lists.

claunia referenced this issue

2026-01-29 14:47:26 +00:00

[PR #308] [MERGED] fix emoji performance issue when multiple pipeline needed #930

claunia referenced this issue

2026-01-29 14:47:27 +00:00

[PR #309] [MERGED] remove lazy initialize #931

claunia referenced this issue

2026-01-29 14:47:30 +00:00

[PR #308] fix emoji performance issue when multiple pipeline needed #935

claunia referenced this issue

2026-01-29 14:47:31 +00:00

[PR #309] remove lazy initialize #936