No-markdown islands

I would push this to be done via generic directive like below. Though it’s probbly not the prettiest syntax compared to something native like HTML CDATA.

!nomarkup[ ...etc... ]

  ...etc ...

Btw, vitaly, will you support $$ latex math block at least?

Personally, i’d prefer to use $$ for asciimath. But i’l do any syntax, that fall into spec. I really need math. The only reason why it’s not implemented yet in remarkable - i wait until math markup become official. Many people need it, and i hope that this question will not be postponed for a long time.

I don’t get what you mean by don’t having guarantee of output presentation, are you falling in the same argument as mb21?

This is just about getting what’s in the islands as verbatim in the output. It’s up to the person editing the file to know for what use his CommonMark source is for, producing HTML, LaTeX or whatever, and then know the best use of the no-markdown literals, let it be for outputing some pieces of MathJax, or just raw LaTeX (which doesn’t need surrounding $…$), etc.

Would it be viable to specify a expression of what to ignore in document declaration? E.g. like No-markdown islands

@vitaly would it be a plausible approach to allow users to specify perhaps a regular expression of what to ignore (definable perhaps in a YAML document header)? I think it would provide the flexibility for @pepper_chico and others to deal with any variety of syntax that needs to be passed through verbatim (thus could be for futureproofing as well).

IMO, I don’t have a problem with that, it’ll work too, although it adds an extra bit of complexity. My suggestion regarding not having problems with clashing delimiters with contents is in the sense of raw string literals existing in programming languages like C++ and Rust (for which I have provided some samples already).

While with the front matter approach you can have a more readable source file where, for effects of reading the CommonMark file, you can readily recognise for what use the islands are there, because they’re self-descriptive even though they produce the same function for output; With a single kind of literal approach, you make it readily recognisable it’s a CommonMark no-markdown literal, and don’t need front matter configuration.

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 >>>>>.

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:


$ cat 
hi \foo

$ pandoc -t native
[Para [Str "hi",Space,RawInline (Format "tex") "\\foo"]]

$ pandoc -t html5
<p>hi </p>

$ pandoc -t latex
hi \foo


$ cat 
hi  $x=42$

$ pandoc -t native
[Para [Str "hi",Space,Math InlineMath "x=42"]]

$ pandoc -t html5
<p>hi <span class="math"><em>x</em> = 42</span></p>

$ pandoc -t html5 --mathjax
<p>hi <span class="math">\(x=42\)</span></p>

$ pandoc -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?


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)



Every time i see paired { } {/ }, i remember 90-x, php and smarty… I can consider it only in terms “better than nothing” :slight_smile:

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.