| should be ignored by the parser when it is within a latex block.
Escaping the pipe with \| is not a solution because \| is also valid latex input.
| | | | | |
|---|---|---|---|---|
| $a|b$ | | | | |
| $a\|b$ | | | | |
| $a\vert b$ | | | | |
Workaroud: if you need | user \vert
Related to Tables, Latex and |
Occurs with or without Custom CSS
Within a table, inline code containing | also includes the escape backslash, displaying \|.
| | | |
-|-|-|-|
a\|b\|c |
`a\|b\|c` |
`a|b|c` |
a\|b\|c
`a\|b\|c`
`a|b|c`
An escaped pipe character (\|) should display in the table as |. A second \ would be required to show the backslash (\\| --> \|)
The escape character also shows, displaying \| in the table, making a standalone pipe (in inline code) unattainable.
Came here to report this. +1
Cool, it works! Thanks a lot.
This appears to be an upstream issue with the markdown parser used for previewing and extracting links, because if you have a table with a cell that contains both something that could be mistaken for a wikilink and one or more vertical bars, the document’s local graph will show the not-a-wikilink. For example:
| Ways of Reading Stdout | Linux | OS X (bash 3.2) | Windows |
| ------------------------------ | --------: | --------------: | -------: |
| `REPLY=$(builtin-or-func...)` | 1187/s | 1369/s | 65/s |
| `read -r < <(builtin-or-f...)` | 2048/s | 1690/s | 68/s |
| `spork read -r -- builtin...` | 6842/s | 5649/s | 3514/s |
| `spork pair w r; builtin...` | 9960/s | 10162/s | 5481/s |
| `[[ ${spork-} ]] || spork ...` | 40433/s | 33840/s | 17667/s |
| Total Performance Improvement | 34.1x | 24.7x | 271.8x |
The editor syntax highlighting handles this table correctly, showing the [[ ${spork-} ]] || line with the correct table separators styled as cm-hmd-table-sep. But the local graph pane will show a bogus link to a nonexistent page named ${spork-}, and the preview mangles the display. This suggests a difference in parsing between the markdown parser used for editing and the one used for previews/metadata extraction.
It looks like maybe Obsidian is using remark-parse version 8? If that’s the case, then this issue was a relevant upstream issue. It appears that this was because they deliberately chose to reproduce a Github upstream bug, but they did not reproduce the Github workaround (which is to backslash-escape the pipe symbols).
Apparently, on Github, backslash-escaping the pipe symbols stops them being interpreted as table delimiters, but the cell parsing then unescapes them before doing low-level parsing, so the cell contents are correctly interpreted as not being escaped (so you don’t render the backslashes). Remark’s attempt to mimic Github’s behavior doesn’t do this, so you end up with bogus backslashes in the rendering.
I have reported the issue upstream as remarkjs/remark #583, so hopefully it can be fixed there, though in all probability this will require Obsidian to upgrade to the newest remark-parse, which has a very different API than the version Obsidian currently appears to be using. But if that is done, then it should fix this for math, latex, and inline code using pipe characters in table cells.
Thanks for the comment. You are corrent. We will eventually upgrade to remark 13 once we deem it stable(r) and more performant.
Good to know! In the meantime I’ve at least been able to verify that this is actually fixed in remark 13, but not in remark 9. (My attempts at repro’ing with remark 13 were actually tripping a different bug in remark 13, so waiting for a more stable version of remark 13 makes sense.
Also, for whatever it’s worth, markdown-it is benchmarked around twice as fast as micromarkdown (the new engine of remark-parse 13), and also lacks this bug. It’s used to implement Prosemirror’s WYSIWYG markdown mode, which might be useful in the future.
Since you’re going to have to switch APIs no matter what when you move from remark-parse 8, it might be worth investigating markdown-it as an alternative, especially if it could ultimately help with creating a true WYSIWYG, and unifying the markdown syntax that’s used in edit and preview modes.
(To be fair, though, Prosemirror’s WYSIWYG markdown mode is more of a tech demo at this point than a drop-in for Obsidian; the schema they’ve developed would need a lot of additions to implement Obsidian’s full feature set. But it’s a good indication of what’s possible, and it looks rather more extensible than Codemirror, in terms of adding rich editing features. It’s also being actively developed, unlike HyperMD.)
we are aware of it, and previously we used markdown-it. We moved to remark because it has more features (especially the AST representation of a document). WYSWYG is tough. We are aware of Prosemirror and a couple of other projects, but no one seems an easy drop-in replacement after digging a bit.