| 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
@jokysatria no because you can escape the pipe in the wikilinks.
You need to use [[aa\|bb]]
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.
Just wondering if there are any updates on this. I have inline code containing regex, but the parser interprets the pipes as table cell dividers despite the pipes being inside the backticks. Escaping with backslashes results in the parser completely ignoring the escaping mechanism and displaying the code as “raw”.
Wrapping the regex in <code> tags does not work either to alleviate this issue.
Using v0.12.19
Here is initial markdown code:
Here is how it looks in preview:
I was unable to find a way to display a table line, containing | symbol.
@Valery_Kondakoff Pipe symbols in table text and wiki links can just be escaped like \|. For LaTeX content in tables you can use the \vert command. But for pipe symbols in code AFAIK there is still no solution.
This is still a problem in v0.13.7 even if the escaped pipe character is in text block
For example
|Link Type|Example|Look ok?|
|---|---|
|note link|```[[target note title]]```|Yes|
|Note link with custom link name|[[custom link name\|target note title```|
|web link|```[Google](https://www.google.com)```|Yes|
Environment: MacOS High Sierra
Obsidian version: 0.13.7
The sad irony is I was making a table of Obsidian link types 
Still hoping for a permanent fix, but found a workaround for the inline code issue.
Wrap it in <code> and escape it.
<code>\|</code>
This worked for me. I can provide system info and versions if it doesn’t work for everyone.
Just wanted to comment that this is still an issue 
(was in the processing of filing a bug report myself). Any idea when a resolution could be expected?
this issue is going to be at least 3 years come July 2023. I don’t think it has been resolved. Those who intend to place code snippets containing the pipe symbol in tables are not able to do so still.
This bug still doesn’t seem to have been resolved since I’m on the latest installer and Obsidian version (1.1.16) and I’m still running into this issue. Are there any updates?
I work with a lot of Linux commands that liberally use pipes. Using a backslash to escape doesn’t seem to work because the code snippet will display it as seen above.
