[Table Extension] Escaped pipe character in code is shown #215

New Issue

claunia · 2026-01-29T14:30:37Z

claunia commented

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

Originally created by @yishengjin1413 on GitHub (Jul 10, 2018).

Hi,

We now have a issue that when escaped pipe in code appear in table. Markdig have different behavior with github. I test on babelmark and here is the example:

|  Category |   Expression      |  Description  |
|-----------|-------------------|---------------|
| D         | `x \| y`          |   Description |
| C         | *x \| y*          |   Description |
| B         |  x \| y           |   Description |
| A         | `x  | y`          |   Description |

Markdig result:

Category	Expression	Description
D	`x \\| y`	Description
C	x \| y	Description
B	x \| y	Description
A	`x \| y`	Description

Github result:

Category	Expression	Description
D	`x \| y`	Description
C	x \| y	Description
B	x \| y	Description
A	`x	y`

Is it possible for markdig to keep the same behavior with github in this case?

Originally created by @yishengjin1413 on GitHub (Jul 10, 2018). Hi, We now have a issue that when escaped pipe in code appear in table. Markdig have different behavior with github. I test on [babelmark](https://babelmark.github.io/?text=%7C++Category+%7C+++Expression++++++%7C++Description++%7C%0A%7C-----------%7C-------------------%7C---------------%7C%0A%7C+D+++++++++%7C+%60x+%5C%7C+y%60++++++++++%7C+++Description+%7C%0A%7C+C+++++++++%7C+*x+%5C%7C+y*++++++++++%7C+++Description+%7C%0A%7C+B+++++++++%7C++x+%5C%7C+y+++++++++++%7C+++Description+%7C%0A%7C+A+++++++++%7C+%60x++%7C+y%60++++++++++%7C+++Description+%7C) and here is the example: ``` | Category | Expression | Description | |-----------|-------------------|---------------| | D | `x \| y` | Description | | C | *x \| y* | Description | | B | x \| y | Description | | A | `x | y` | Description | ``` Markdig result: <table> <thead> <tr> <th> Category </th> <th> Expression </th> <th> Description </th> </tr> </thead> <tbody> <tr> <td> D </td> <td> <code>x \| y</code> </td> <td> Description </td> </tr> <tr> <td> C </td> <td> <em>x | y</em> </td> <td> Description </td> </tr> <tr> <td> B </td> <td> x | y </td> <td> Description </td> </tr> <tr> <td> A </td> <td> <code>x | y</code> </td> <td> Description </td> </tr> </tbody> </table> Github result: <table> <thead> <tr> <th> Category </th> <th> Expression </th> <th> Description </th> </tr> </thead> <tbody> <tr> <td> D </td> <td> <code>x | y</code> </td> <td> Description </td> </tr> <tr> <td> C </td> <td> <em>x | y</em> </td> <td> Description </td> </tr> <tr> <td> B </td> <td> x | y </td> <td> Description </td> </tr> <tr> <td> A </td> <td> `x </td> <td> y` </td> </tr> </tbody> </table> Is it possible for markdig to keep the same behavior with github in this case?

claunia added the enhancement label 2026-01-29 14:30:37 +00:00

claunia closed this issue

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

claunia commented

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

@Kryptos-FR commented on GitHub (Jul 10, 2018):

To me it is actually the GitHub version that is incorrect. Anything inside `` should be verbatim.
Maybe raise a similar issue in the GitHub repository (linking to that one) and let's see what they think of it.

@Kryptos-FR commented on GitHub (Jul 10, 2018): To me it is actually the GitHub version that is incorrect. Anything inside `` should be verbatim. Maybe raise a similar issue in the GitHub repository (linking to that one) and let's see what they think of it.

claunia commented

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

@yishengjin1413 commented on GitHub (Jul 10, 2018):

Thanks @Kryptos-FR for your interesting about this issue. I agree with you. Do you know how to open a public issue to github?

@yishengjin1413 commented on GitHub (Jul 10, 2018): Thanks @Kryptos-FR for your interesting about this issue. I agree with you. Do you know how to open a public issue to github?

claunia commented

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

@xoofx commented on GitHub (Jul 10, 2018):

This is a known issue. The previous implementation of tables in Markdown at GitHub was performing a split on the final HTML in order to create the table (!), so they have simply replicated this poor behavior. Unfortunately, they will unlikely change this because they have now a legacy to be compatible with...

This is one question I asked a while ago while implementing tables for markdig, I came with the solution of doing it more properly using the parser information instead of going through text/character split. The GitHub developer behind the new implementation (cmark fork), gave some insights about how they implemented the pipe table

We should probably have an option for GitHub pipe table parser... that would trigger a completely different parser (instead of trying to adapt the current which I would like to kept as it is, as it is more accurate)

@xoofx commented on GitHub (Jul 10, 2018): This is a known issue. The previous implementation of tables in Markdown at GitHub was performing a split on the final HTML in order to create the table (!), so they have simply replicated this poor behavior. Unfortunately, they will unlikely change this because they have now a legacy to be compatible with... This is one question I asked a while ago while implementing tables for markdig, I came with the solution of doing it more properly using the parser information instead of going through text/character split. The GitHub developer behind the new implementation (cmark fork), gave some insights about [how they implemented the pipe table](https://talk.commonmark.org/t/parsing-strategy-for-tables/2027/46?u=xoofx) We should probably have an option for GitHub pipe table parser... that would trigger a completely different parser (instead of trying to adapt the current which I would like to kept as it is, as it is more accurate)

claunia commented

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

@yishengjin1413 commented on GitHub (Jul 11, 2018):

Thanks @xoofx , very useful information. I will keep the markdig behavior for now. I think it's more clear too.

@yishengjin1413 commented on GitHub (Jul 11, 2018): Thanks @xoofx , very useful information. I will keep the markdig behavior for now. I think it's more clear too.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/markdig#215