Codeinline in table #166

New Issue

claunia · 2026-01-29T14:29:19Z

claunia commented

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

Originally created by @yishengjin1413 on GitHub (Nov 29, 2017).

@xoofx I found an issue for codeinline in table, see the follow example:

`ds|a
-|-
fd|y`

it will be rendered as :

<p>
  <code>ds|a -|- fd|y</code>
</p>

Would you like to follow table rule here?

If you don't got enough time to fix this, I can help to provide a PR.

BTW, is there any reason why PipeTableParser is a InlineParser? It's should more like a BlockParser. Seems all the leafinline rule (which can contain '|') will break the table in this way.

Originally created by @yishengjin1413 on GitHub (Nov 29, 2017). @xoofx I found an issue for codeinline in table, see the follow example: ``` `ds|a -|- fd|y` ``` it will be rendered as : ``` <p> <code>ds|a -|- fd|y</code> </p> ``` Would you like to follow table rule [here](https://github.github.com/gfm/#tables-extension-)? If you don't got enough time to fix this, I can help to provide a PR. BTW, is there any reason why PipeTableParser is a InlineParser? It's should more like a BlockParser. Seems all the leafinline rule (which can contain '|') will break the table in this way.

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

claunia commented

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

@xoofx commented on GitHub (Nov 29, 2017):

The reason for this parsing strategy was detailed a bit in this discussion

So if you look on babelmark, for this example:

ds|a|b
-|-|-
fd`|`y|c|d

we are getting quite different results.

BTW, is there any reason why PipeTableParser is a InlineParser? It's should more like a BlockParser. Seems all the leafinline rule (which can contain '|') will break the table in this way.

So the parsing strategy was to allow backstick (but also other inlines, like HTML inline where you could use | inside an attribute) to work accordingly so that if a | is put inside, it is not detected as a | of the table.

But also looking at this example:

| c | d |
| - | - |
| *a | b* |
| `e | f` |
| [g | h](http://a.com) |

I can see that now GitHub is handling things quite differently from what I remember...

So, hm, maybe we should have a a pipetable parser option to allow github like parsing that is going to be quite different from the parsing we have today... so likely implemented entirely in separate method (if we want to keep a single Pipetable parser with configurable options).

I don't have time right now for this, so let me know if you could come up with something.

@xoofx commented on GitHub (Nov 29, 2017): The reason for this parsing strategy was detailed a bit in [this discussion](https://talk.commonmark.org/t/parsing-strategy-for-tables/2027/21) So if you look on babelmark, for [this example](https://babelmark.github.io/?text=ds%7Ca%7Cb%0A-%7C-%7C-%0Afd%60%7C%60y%7Cc%7Cd): ```md ds|a|b -|-|- fd`|`y|c|d ``` we are getting quite different results. > BTW, is there any reason why PipeTableParser is a InlineParser? It's should more like a BlockParser. Seems all the leafinline rule (which can contain '|') will break the table in this way. So the parsing strategy was to allow backstick (but also other inlines, like HTML inline where you could use `|` inside an attribute) to work accordingly so that if a `|` is put inside, it is not detected as a `|` of the table. But also looking at [this example](https://babelmark.github.io/?text=%7C+c+%7C+d+%7C%0A%7C+-+%7C+-+%7C%0A%7C+*a+%7C+b*+%7C%0A%7C+%60e+%7C+f%60+%7C%0A%7C+%5Bg+%7C+h%5D(http%3A%2F%2Fa.com)+%7C): ``` | c | d | | - | - | | *a | b* | | `e | f` | | [g | h](http://a.com) | ``` I can see that now GitHub is handling things quite differently from what I remember... So, hm, maybe we should have a a pipetable parser option to allow github like parsing that is going to be quite different from the parsing we have today... so likely implemented entirely in separate method (if we want to keep a single Pipetable parser with configurable options). I don't have time right now for this, so let me know if you could come up with something.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/markdig#166