[Pipe Tables Extension] Rendering tables when delimiter row is invalid #388

New Issue

claunia · 2026-01-29T14:35:34Z

claunia commented

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

Originally created by @hamvocke on GitHub (Jul 31, 2020).

I found another aspect where the pipe tables extension is doing things differently than what GitHub-flavored Markdown suggests. While we're at it, maybe we can get another tweak in for a more GFM-compliant way of processing? 🙂

This is the example I'm talking about:

The header row must match the delimiter row in the number of cells. If not, a table will not be recognized

In other words, a table like this should not be recognized as a table because the delimiter row doesn't match the number of header cells.

| abc | def |
| --- |
| bar |

Markdig would still render the structure given above as a table with two columns.

With the new gfm-pipetables mode in place I managed to get a failing test to reproduce the issue but I'm unsure where to get the fix in. In my mind, the check would go somewhat like this:

tokenize header row
tokenize delimiter row
compare length of both and bail if the length isn't equal

There might be another way to do this that's more in line with the current architecture, though. I'm happy to work on a fix for this issue but would appreciate some ideas to get started.

Originally created by @hamvocke on GitHub (Jul 31, 2020). I found another aspect where the pipe tables extension is doing things differently than what GitHub-flavored Markdown suggests. While we're at it, maybe we can get another tweak in for a more GFM-compliant way of processing? 🙂 [This is the example I'm talking about](https://github.github.com/gfm/#example-203): > The header row must match the delimiter row in the number of cells. If not, a table will not be recognized In other words, a table like this should not be recognized as a table because the delimiter row doesn't match the number of header cells. ``` | abc | def | | --- | | bar | ``` Markdig would still render the structure given above as a table with two columns. With the new `gfm-pipetables` mode in place I managed to get a failing test to reproduce the issue but I'm unsure where to get the fix in. In my mind, the check would go somewhat like this: 1. tokenize header row 2. tokenize delimiter row 3. compare length of both and bail if the length isn't equal There might be another way to do this that's more in line with the current architecture, though. I'm happy to work on a fix for this issue but would appreciate some ideas to get started.

claunia added the enhancement PR Welcome! labels 2026-01-29 14:35:34 +00:00

claunia commented

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

@xoofx commented on GitHub (Jul 31, 2020):

Gonna be on holidays for the upcoming 3 weeks, so don't worry If I'm not super responding or not able to merge PR quickly 😉

@xoofx commented on GitHub (Jul 31, 2020): Gonna be on holidays for the upcoming 3 weeks, so don't worry If I'm not super responding or not able to merge PR quickly 😉

claunia referenced this issue

2026-01-29 14:48:06 +00:00

[PR #388] [CLOSED] Optimized LineReader using string.IndexOfAny #979

claunia referenced this issue

2026-01-29 14:48:07 +00:00

[PR #388] Optimized LineReader using string.IndexOfAny #983

claunia referenced this issue

2026-01-29 14:48:11 +00:00

[PR #393] [MERGED] Optimize LineReader.ReadLine #986

claunia referenced this issue

2026-01-29 14:48:15 +00:00

[PR #393] Optimize LineReader.ReadLine #991