Changes between Version 2 and Version 3 of MarkDown
- Timestamp:
- Apr 8, 2016, 8:46:51 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MarkDown
v2 v3 1 [[PageOutline(2-3,Contents)]] 2 1 3 = Markdown 2 4 3 [[PageOutline(2-3)]] 4 5 [http://daringfireball.net/projects/markdown/basics/ Markdown] is a semi-structured markup language originally designed for blogs which is now used in several wikis as well. 6 7 It's now widely used in the software developer community because it's the preferred authoring markup used by GitHub and StackOverflow. 5 [http://daringfireball.net/projects/markdown/basics/ Markdown] is a semi-structured markup language originally designed for blogs, which is now used in several wikis as well. 6 7 It is now widely used in the software developer community, because it is the preferred authoring markup used by GitHub and StackOverflow. 8 8 See [http://github.github.com/github-flavored-markdown/ Introduction to GFM] and [http://stackoverflow.com/editing-help/ Markdown help] respectively for what variant is supported in each. 9 9 10 A lot of this is close to WikiCreole, ReST and our own markup. Most of the time, the markdown syntax makes a lot of sense and would fit well with our current syntax (in particular the rules for nesting paragraphs). And the rest is damn interesting as well! 11 12 The new WikiEngine should make it possible to implement optional or conditional support for Markdown, for the features that conflict with the current syntax. 13 14 So let's go through the details of the basic syntax, of the advanced syntax and of its popular extensions. 15 10 The syntax shares many similarities with WikiCreole, ReST and our own markup. Therefore, the markdown syntax would fit well with our current syntax, in particular the rules for nesting paragraphs. The new WikiEngine should also make it possible to implement optional or conditional support for Markdown, for the features that conflict with the current syntax. 11 12 This page lists the details of the basic syntax, the advanced syntax and its popular extensions. 16 13 17 14 == [http://daringfireball.net/projects/markdown/basics Basic features] 18 15 19 16 === PARAGRAPHS, HEADERS, BLOCKQUOTES 17 20 18 {{{ 21 19 A First Level Header … … 71 69 }}} 72 70 73 This is a huge win and one of the main motivat or behind the new engine... (see #8140, #1936)71 This is a huge win and one of the main motivations behind the new engine. (see #8140, #1936) 74 72 75 73 === LINKS … … 79 77 This is an [example link](http://example.com/). 80 78 }}} 79 81 80 and that: 82 81 {{{ … … 84 83 }}} 85 84 86 87 85 References: 86 88 87 {{{ 89 88 I get 10 times more traffic from [Google][1] than from … … 99 98 [ny times]: http://www.nytimes.com/ 100 99 }}} 101 ... challenging.102 100 103 101 === IMAGES … … 110 108 [id]: /path/to/img.jpg "Title" 111 109 }}} 110 112 111 So we'll have to find another way than the usual `!...` for escaping links. In Markdown, it's usually `\` which is used for escaping markup. 113 112 … … 116 115 [](http://travis-ci.org/libgit2/libgit2) 117 116 }}} 118 i.e. the image link can be written inside the label part of a normal link (like other inline markup). 119 120 ... challenging again! But we also wanted that already for our own TracLinks, see #9123. 121 122 Note that some tricky stuff like {{{[`o]o`](http://example.com)}}} easily confuses the GitHub parser... 123 117 118 i.e. the image link can be written inside the label part of a normal link (like other inline markup), which can be a challenge! But we also wanted that already for our own TracLinks, see #9123. 119 120 Note that tricky stuff like {{{[`o]o`](http://example.com)}}} easily confuses the GitHub parser. 124 121 125 122 === CODE … … 127 124 We have {{{`...`}}} also. 128 125 129 But see below. ..126 But see below. 130 127 131 128 == [http://daringfireball.net/projects/markdown/syntax Advanced features] … … 144 141 This is another regular paragraph. 145 142 }}} 143 146 144 The original spec mention that the content of these elements is not parsed as Markdown, but some [http://michelf.ca/projects/php-markdown/extra/#markdown-attr extensions] allow for it. 147 145 … … 149 147 150 148 === BLOCKQUOTES 149 151 150 "Markdown allows you to be lazy and only put the > before the first line of a hard-wrapped paragraph:" 152 151 {{{ … … 172 171 }}} 173 172 174 Damn, this breaks the base assumption of the [TracDev/Proposals/VerticalHorizontalParsing vertical/horizontal parsing]. 175 173 This breaks the base assumption of the [TracDev/Proposals/VerticalHorizontalParsing vertical/horizontal parsing]. 176 174 177 175 === CODE … … 181 179 }}} 182 180 183 184 181 == [https://help.github.com/articles/github-flavored-markdown GitHub Flavored Markdown] 185 182 … … 192 189 Sure, perform_complicated_task shouldn't become perform//complicated//task. 193 190 194 We could even auto-verbatim these. ..191 We could even auto-verbatim these. 195 192 196 193 === URL autolinking 197 194 198 We have .195 We have this feature already. 199 196 200 197 === Fenced code blocks … … 216 213 === [https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments Task Lists] 217 214 218 Aha! Thought about them since a long time, and finally GitHub did it. ..219 220 It's only possible to support i f we're able to rewrite the original wiki text from the parsed data.215 Aha! Thought about them since a long time, and finally GitHub did it. 216 217 It's only possible to support it if we're able to rewrite the original wiki text from the parsed data. 221 218 222 219 === Quick quoting … … 226 223 === Name and Team @mentions autocomplete 227 224 228 Once we have a better notion of users ... 229 230 But `@user` syntax seems to have become the de-facto standard (I would have preferred ~user though). 225 Once we have a better notion of users. But `@user` syntax seems to have become the de-facto standard (I would have preferred ~user though). 231 226 232 227 Auto-complete could be used for a great deal of other things (WikiPageNames and WikiMacros, source paths, attachment names, etc. See #9296). … … 246 241 === Closing issues via commit messages 247 242 248 We have .243 We have this feature already. 249 244 250 245 === References 246 251 247 {{{ 252 248 * SHA: be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2 … … 257 253 * User/Project#Num: mojombo/god#1 258 254 }}} 259 References to SHA1 numbers are/should be unique enough for not having to ask the user to add the repository name. However, if it's added then we know explicitly where to go (in case the same commit is present in multiple repositories). 255 256 References to SHA1 numbers are/should be unique enough for not having to ask the user to add the repository name. However, if it's added, then we know explicitly where to go (in case the same commit is present in multiple repositories). 260 257 261 258 == [http://michelf.ca/projects/php-markdown/extra/ Markdown Extra] … … 273 270 * definition lists 274 271 * glossary entries (LaTeX only) 275 * document metadata (e.g. title, author, etc.) 276 277 278 ----- 279 (to be continued) 280 ----- 272 * document metadata, such as title, author, etc. 273 281 274 == [http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown Pandoc] 282 275 283 284 276 == [http://www.pell.portland.or.us/~orc/Code/markdown/ Discount] 285 277 286 287 278 == [http://stackoverflow.com/editing-help StackOverflow extensions] 288 279 289 290 280 == [http://rdoc.rubyforge.org/RDoc/Markdown.html RDoc Markdown] 291 281
