I don’t know. Processing options is completely out of current spec. Don’t think it’s a good idea to mix with markup. I’m for solving particular cases instead of generic, when possible. Math worth to have separate syntax for readability, because used very wide. I’m interested in math inlines only. My advices for other inlines will be not relevant.
So if I understand, you want a syntax for any particular no markdown island that wont clash with anything?
>>>>>>>>>>>>>>>
Some random weird C Rust Etc...
<<<<<<<<<<<<<<<
Maybe something like this, where the number of > must match the same number of < or something like that. As for maths, well I’ll stick to $ and $$ convention.
When you say, “as for math” does it mean such literals have any other purpose beyond “no-markdown here”? Because if it doesn’t do anything beyond that, this no-markdown suggestion can just be an extension of that. Like $, $$, $$$, $$$$$… instead of >>>>>.
EDIT:
Ah, sorry my bad, I got confused with my own proposal, it can’t be that way, because the delimiters get in the output for MathJax, while for this proposal they don’t.
fair enough, well what do you think about the proposal? Any issue with this approach? I think it’s pretty obvious to me, but wonder what you think.
(notice I’ve made an edit to my last post)
I’m not sure which approach you’re talking about, the front matter one?
Oh you mean this?
$$$$$$$$$$$
Some random weird C Rust Etc...
$$$$$$$$$$$
that works for me as well. And I agree it’s intuitive.
To approach vitaly’s issue of how to deal with various maths handling… maybe
$$$$$$$$$$$ { .ASCIImath }
... math here ...
$$$$$$$$$$$
This would keep to the same convention for code syntax highlighting. But instead of highlighting, it lets the parser knows to treat it with the right escape for the math type.
I was mentioning the last edit =/ where I say with the MathJax approach being used in the wide, $$ delimiters go to the output, while with this proposal, delimiters should not do it (because it may not be MathJax in the output, but other verbatim thing).
Ah, so vitaly was saying about presentation for highlighting the CommonMark, not rendering in the output. Well, all along I was not thinking about this since I don’t find this a must, just no-highlighting for me would do fine.
Okay, I’m going to try to understand this a second time. IIRC there are two use-cases up to now: math and raw TeX. Pandoc solves those by recognizing the $ and \ characters and in effect creates no-markdown islands for those:
TeX:
$ cat test.md
hi \foo
$ pandoc test.md -t native
[Para [Str "hi",Space,RawInline (Format "tex") "\\foo"]]
$ pandoc test.md -t html5
<p>hi </p>
$ pandoc test.md -t latex
hi \foo
Math:
$ cat test2.md
hi $x=42$
$ pandoc test2.md -t native
[Para [Str "hi",Space,Math InlineMath "x=42"]]
$ pandoc test2.md -t html5
<p>hi <span class="math"><em>x</em> = 42</span></p>
$ pandoc test2.md -t html5 --mathjax
<p>hi <span class="math">\(x=42\)</span></p>
$ pandoc test2.md -t latex
hi $x=42$
So the questions is whether this is a good approach for CommonMark as well, or whether we need a no-markdown island syntax, correct?
2 Likes
Sounds fine by me. But if no-markdown island is still needed. Fenced \\\ could be an option:
\\\
Fenced raw unparsed text
So this will directly appear in source code untouched.
\\\
As for inline, hard to say what is safe (since \ is used for windows file system address), but this comes to mind:
[\\ directly unparsed text here \\][\\ ... \\] is confusingly similar to \\[ ... \\] display math syntax used by some impementations.
kramdown extension syntax might be better (on top of being already in an implementation)
{::name}
{:/name}
Every time i see paired { } {/ }, i remember 90-x, php and smarty… I can consider it only in terms “better than nothing” 
1 Like
we have @foo{} stuff that reminds me texinfo, there is the {} stuff with the : that is some kind of mustache or jinja. Sadly there is no escape. I prefer copying kramdown as much as possible since it is already known to work well.
Block Directives see from that post and below, and link in that post.
Fenced-style blocks are more practical, because allow nesting without pain.