Edit table don't recognize escaped |

[andermikael]

I have a table that has a pipe character | in it's value
If I escape the character with an backslash then it looks OK in the preview.
But if I Edit Table then it takes the escaped pipe as an actual pipe and I get a new column.
I also tried to mark the pipe as code but I got the same result!

My test table

| keyword   | values|
|-----------|-----------------------------------------------|
| time      | C, C\| , #/# |

• MM 2.4.6.3
• MarkDig
• Win 10

// Anders

[RickStrahl]

Yeah this is a definite bug, but at the moment there's no good workaround because the parsing physically parses out the | to mean the separator - there's no context of how the separator is used - ie. escaped or quoted.

The escape scenario can be handled somewhat easily by transforming the string and resetting after parsing, but the use case of code is something that i don't have an idea on how to handle.

Couple of things come to mind:

• Using Markdigs document parsing to actually parse the table (unsure if that's actually supported)
• Render the table to HTML then capture the HTML instead

The first would work if Markdig supports peeling out the cells and that would be idea. The latter is problematic because it might render away some of the raw Markdown Markup you can potentially use (ie. bold/italic/code etc.)

Have to give this one some thought.

[RickStrahl]

Actually a (ugly) workaround is to HTML escape the value |:

[RickStrahl]

So after a little experimenting I can make the first escaped scenario work with a relatively simple fix using text replacements:

However, the code scenario (the second table in the Markdown editor won't work there. That'll require actual parsing of the markdown inside of the cell to determine context - not sure if I want to go down that path 😄

[andermikael]

If escape using \ works then that's the preferred way of doing it!
No need for using code or html escape...

[RickStrahl]

Well, yes, it's preferred in your use case but it may be a requirement for another use case (like the second example).

The fix for your exact issue will go into the next update. I'll give some more thought to how to address the embedded code scenario.

[RickStrahl]

So this has been fixed for 2.4.6.4 for the escaped pipe (ie. \|) scenario.

The code scenario is not handled and will leave that as an uncommon edge case if it comes up again in the future (unlikely).