Mardown is a simple markup language, designed to be converted to HTML.
# this is 1st level heading something something. This is a paragraph. ## this is 2nd level heading ### this is 3rd level heading heading is supported up to 6 levels
one backtick: `x = 3` two backtick also works: ``y = 4``
Bracket by lines, each line is 3 (or more) GRAVE ACCENT characters and nothing else.
here's the code ``` x = 4 print(x) ``` ```` 4 backticks also works ```` that's it.
alternatively, 4 space indentation (or 1 tab), with a blank line before:
here's the code x = 4 print(x) that's it.
asterisks for italic: *important* 2 asterisks for bold: **critical** LOW LINE can also be used: italics: _important_ bold : __important__
precede each line with GREATER-THAN SIGN >:
He said: > something something > something else > and more
precede each line with asterisk.
here's a list * 1st item * another item * and 3rd item or dash - 1st item - another item - and 3rd item
1. 1st item 2. another item 3. and 3rd item
Use indent by 2 spaces: 1. something 1. and more 2. so much more 2. Secondly, * this is seconod sublist * and 3rd level list * 2nd item of 3rd level list 3. and lastly.
Google search site is (http://google.com/)
Markdown Filename Extension
Markdown filename extension is
How to convert markdown to HTML?
Code to convert markdown to html is available in all major programing languages.
Spec and code at https://commonmark.org/
problems of markdown syntax
was planinig to write a markdown to html in xah html mode. to do so, one needs to decide on the syntax. i decide now, markdown syntax is not good. same conclusion i had i think decade ago.
worst offender is the GREATER-THAN SIGN for block quote. e.g.
> text > block > quote > syntax
required for each and every line. this btw, came from unix fuck.
Other problems, is duplicate syntax. E.g. - and * can be used both for list, or bold/underline. And # the header, can also be done by having ============== under it.
The whole saga of CommonMark, 10 years ago, seems in vain. They didn't fix the issues am concerned above. Instead, they focused on the parsing ambiguity. And they actually tried to be compatible as much as possible. In other words, the whole CommonMark effort, is on nerd backend technicality, not the design of the syntax.