rdiscount 1.6.3.1 → 1.6.3.2

Sign up to get free protection for your applications and to get access to all the features.
data/Rakefile CHANGED
@@ -34,6 +34,18 @@ end
34
34
  desc 'Build the rdiscount extension'
35
35
  task :build => "lib/rdiscount.#{DLEXT}"
36
36
 
37
+ # ==========================================================
38
+ # Manual
39
+ # ==========================================================
40
+
41
+ file 'man/rdiscount.1' => 'man/rdiscount.1.ronn' do
42
+ sh "ronn --manual=RUBY -b man/rdiscount.1.ronn"
43
+ end
44
+ CLOBBER.include 'man/rdiscount.1'
45
+
46
+ desc 'Build manpages'
47
+ task :man => 'man/rdiscount.1'
48
+
37
49
  # ==========================================================
38
50
  # Testing
39
51
  # ==========================================================
@@ -106,6 +118,7 @@ task :gather => 'discount' do |t|
106
118
  cp files, 'ext/',
107
119
  :preserve => true,
108
120
  :verbose => true
121
+ cp 'discount/markdown.7', 'man/'
109
122
  end
110
123
 
111
124
  # best. task. ever.
@@ -128,31 +141,30 @@ end
128
141
 
129
142
  # PACKAGING =================================================================
130
143
 
131
- if defined?(Gem)
132
- $spec = eval(File.read('rdiscount.gemspec'))
144
+ require 'rubygems'
145
+ $spec = eval(File.read('rdiscount.gemspec'))
133
146
 
134
- def package(ext='')
135
- "pkg/rdiscount-#{$spec.version}" + ext
136
- end
147
+ def package(ext='')
148
+ "pkg/rdiscount-#{$spec.version}" + ext
149
+ end
137
150
 
138
- desc 'Build packages'
139
- task :package => %w[.gem .tar.gz].map {|e| package(e)}
151
+ desc 'Build packages'
152
+ task :package => %w[.gem .tar.gz].map {|e| package(e)}
140
153
 
141
- desc 'Build and install as local gem'
142
- task :install => package('.gem') do
143
- sh "gem install #{package('.gem')}"
144
- end
154
+ desc 'Build and install as local gem'
155
+ task :install => package('.gem') do
156
+ sh "gem install #{package('.gem')}"
157
+ end
145
158
 
146
- directory 'pkg/'
159
+ directory 'pkg/'
147
160
 
148
- file package('.gem') => %w[pkg/ rdiscount.gemspec] + $spec.files do |f|
149
- sh "gem build rdiscount.gemspec"
150
- mv File.basename(f.name), f.name
151
- end
161
+ file package('.gem') => %w[pkg/ rdiscount.gemspec] + $spec.files do |f|
162
+ sh "gem build rdiscount.gemspec"
163
+ mv File.basename(f.name), f.name
164
+ end
152
165
 
153
- file package('.tar.gz') => %w[pkg/] + $spec.files do |f|
154
- sh "git archive --format=tar HEAD | gzip > #{f.name}"
155
- end
166
+ file package('.tar.gz') => %w[pkg/] + $spec.files do |f|
167
+ sh "git archive --format=tar HEAD | gzip > #{f.name}"
156
168
  end
157
169
 
158
170
  # GEMSPEC HELPERS ==========================================================
data/bin/rdiscount CHANGED
@@ -1,5 +1,13 @@
1
1
  #!/usr/bin/env ruby
2
+ # Usage: rdiscount [<file>...]
3
+ # Convert one or more Markdown files to HTML and write to standard output. With
4
+ # no <file> or when <file> is '-', read Markdown source text from standard input.
5
+ if ARGV.include?('--help')
6
+ File.read(__FILE__).split("\n").grep(/^# /).each do |line|
7
+ puts line[2..-1]
8
+ end
9
+ exit 0
10
+ end
2
11
 
3
- $: << File.expand_path(File.dirname(__FILE__) + "/../lib")
4
12
  require 'rdiscount'
5
13
  STDOUT.write(RDiscount.new(ARGF.read).to_html)
data/ext/config.h CHANGED
@@ -18,3 +18,4 @@
18
18
  #endif
19
19
 
20
20
  #define RELAXED_EMPHASIS 1
21
+ #define SUPERSCRIPT 1
data/ext/markdown.c CHANGED
@@ -36,7 +36,9 @@ static struct kw blocktags[] = { KW("!--"), KW("STYLE"), KW("SCRIPT"),
36
36
  KW("UL"), KW("P"), KW("OL"), KW("DL"),
37
37
  KW("PLAINTEXT"), KW("PRE"), KW("TABLE"),
38
38
  KW("WBR"), KW("XMP"), SC("HR"), SC("BR"),
39
- KW("IFRAME"), KW("MAP") };
39
+ KW("IFRAME"), KW("MAP"), KW("ARTICLE"),
40
+ KW("ASIDE"), KW("FOOTER"), KW("HEADER"),
41
+ KW("HGROUP"), KW("NAV"), KW("SECTION") };
40
42
  #define SZTAGS (sizeof blocktags / sizeof blocktags[0])
41
43
  #define MAXTAG 11 /* sizeof "BLOCKQUOTE" */
42
44
 
data/lib/rdiscount.rb CHANGED
@@ -24,7 +24,7 @@
24
24
  # end
25
25
  #
26
26
  class RDiscount
27
- VERSION = '1.6.3.1'
27
+ VERSION = '1.6.3.2'
28
28
 
29
29
  # Original Markdown formatted text.
30
30
  attr_reader :text
data/man/markdown.7 ADDED
@@ -0,0 +1,1020 @@
1
+ .\"
2
+ .Dd Dec 22, 2007
3
+ .Dt MARKDOWN 7
4
+ .Os MASTODON
5
+ .Sh NAME
6
+ .Nm Markdown
7
+ .Nd The Markdown text formatting syntax
8
+ .Sh DESCRIPTION
9
+ .Ss Philosophy
10
+ .Nm Markdown
11
+ is intended to be as easy-to-read and easy-to-write as is feasible.
12
+ .Pp
13
+ Readability, however, is emphasized above all else. A Markdown-formatted
14
+ document should be publishable as-is, as plain text, without looking
15
+ like it's been marked up with tags or formatting instructions. While
16
+ Markdown's syntax has been influenced by several existing text-to-HTML
17
+ filters -- including
18
+ .Em Setext ,
19
+ .Em atx ,
20
+ .Em Textile ,
21
+ .Em reStructuredText ,
22
+ .Em Grutatext ,
23
+ and
24
+ .Em EtText
25
+ \-\- the single biggest source of
26
+ inspiration for
27
+ Markdown's
28
+ syntax is the format of plain text email.
29
+ .Pp
30
+ To this end, Markdown's syntax is comprised entirely of punctuation
31
+ characters, which punctuation characters have been carefully chosen so
32
+ as to look like what they mean. E.g., asterisks around a word actually
33
+ look like *emphasis*. Markdown lists look like, well, lists. Even
34
+ blockquotes look like quoted passages of text, assuming you've ever
35
+ used email.
36
+ .Ss Inline HTML
37
+ Markdown's syntax is intended for one purpose: to be used as a
38
+ format for
39
+ .Em writing
40
+ for the web.
41
+ .Pp
42
+ .Nm
43
+ is not a replacement for HTML, or even close to it. Its
44
+ syntax is very small, corresponding only to a very small subset of
45
+ HTML tags. The idea is
46
+ .Em not
47
+ to create a syntax that makes it easier
48
+ to insert HTML tags. In my opinion, HTML tags are already easy to
49
+ insert. The idea for Markdown is to make it easy to read, write, and
50
+ edit prose. HTML is a
51
+ .Em publishing
52
+ format; Markdown is a
53
+ .Em writing
54
+ format. Thus, Markdown's formatting syntax only addresses issues that
55
+ can be conveyed in plain text.
56
+ .Pp
57
+ For any markup that is not covered by Markdown's syntax, you simply
58
+ use HTML itself. There's no need to preface it or delimit it to
59
+ indicate that you're switching from Markdown to HTML; you just use
60
+ the tags.
61
+ .Pp
62
+ The only restrictions are that block-level HTML elements -- e.g.
63
+ .Li \<div> ,
64
+ .Li \<table> ,
65
+ .Li \<pre> ,
66
+ .Li \<p> ,
67
+ etc. -- must be separated from surrounding
68
+ content by blank lines, and the start and end tags of the block should
69
+ not be indented with tabs or spaces. Markdown is smart enough not
70
+ to add extra (unwanted)
71
+ .Li \<p>
72
+ tags around HTML block-level tags.
73
+ .Pp
74
+ For example, to add an HTML table to a Markdown article:
75
+ .Bd -literal -offset indent
76
+ This is a regular paragraph.
77
+
78
+ <table>
79
+ <tr>
80
+ <td>Foo</td>
81
+ </tr>
82
+ </table>
83
+
84
+ This is another regular paragraph.
85
+ .Ed
86
+ .Pp
87
+ Note that Markdown formatting syntax is not processed within block-level
88
+ HTML tags. E.g., you can't use Markdown-style
89
+ .Li *emphasis*
90
+ inside an HTML block.
91
+ .Pp
92
+ Span-level HTML tags -- e.g.
93
+ .Li \<span> ,
94
+ .Li \<cite> ,
95
+ or
96
+ .Li \<del>
97
+ \-\- can be
98
+ used anywhere in a Markdown paragraph, list item, or header. If you
99
+ want, you can even use HTML tags instead of Markdown formatting; e.g. if
100
+ you'd prefer to use HTML
101
+ .Li \<a>
102
+ or
103
+ .Li \<img>
104
+ tags instead of Markdown's
105
+ link or image syntax, go right ahead.
106
+ .Pp
107
+ Unlike block-level HTML tags, Markdown syntax *is* processed within
108
+ span-level tags.
109
+ .Ss Automatic Escaping for Special Characters
110
+ In HTML, there are two characters that demand special treatment: `<`
111
+ and `&`. Left angle brackets are used to start tags; ampersands are
112
+ used to denote HTML entities. If you want to use them as literal
113
+ characters, you must escape them as entities, e.g. `&lt;`, and
114
+ `&amp;`.
115
+ .Pp
116
+ Ampersands in particular are bedeviling for web writers. If you want to
117
+ write about 'AT&T', you need to write '`AT&amp;T`'. You even need to
118
+ escape ampersands within URLs. Thus, if you want to link to:
119
+ .Bd -literal -offset indent
120
+ http://images.google.com/images?num=30&q=larry+bird
121
+ .Ed
122
+ .Pp
123
+ you need to encode the URL as:
124
+ .Bd -literal -offset indent
125
+ http://images.google.com/images?num=30&amp;q=larry+bird
126
+ .Ed
127
+ .Pp
128
+ in your anchor tag `href` attribute. Needless to say, this is easy to
129
+ forget, and is probably the single most common source of HTML validation
130
+ errors in otherwise well-marked-up web sites.
131
+ .Pp
132
+ .Nm
133
+ allows you to use these characters naturally, taking care of
134
+ all the necessary escaping for you. If you use an ampersand as part of
135
+ an HTML entity, it remains unchanged; otherwise it will be translated
136
+ into `&amp;`.
137
+ .Pp
138
+ So, if you want to include a copyright symbol in your article, you can write:
139
+ .Bd -literal -offset indent
140
+ &copy;
141
+ .Ed
142
+ .Pp
143
+ and Markdown will leave it alone. But if you write:
144
+ .Bd -literal -offset indent
145
+ AT&T
146
+ .Ed
147
+ .Pp
148
+ .Nm
149
+ will translate it to:
150
+ .Bd -literal -offset indent
151
+ AT&amp;T
152
+ .Ed
153
+ .Pp
154
+ Similarly, because Markdown supports inline HTML, if you use
155
+ angle brackets as delimiters for HTML tags, Markdown will treat them as
156
+ such. But if you write:
157
+ .Bd -literal -offset indent
158
+ 4 < 5
159
+ .Ed
160
+ .Pp
161
+ .Nm
162
+ will translate it to:
163
+ .Bd -literal -offset indent
164
+ 4 &lt; 5
165
+ .Ed
166
+ .Pp
167
+ However, inside Markdown code spans and blocks, angle brackets and
168
+ ampersands are *always* encoded automatically. This makes it easy to use
169
+ Markdown to write about HTML code. (As opposed to raw HTML, which is a
170
+ terrible format for writing about HTML syntax, because every single `<`
171
+ and `&` in your example code needs to be escaped.)
172
+ .Sh Block Elements
173
+ .Ss Paragraphs and Line Breaks
174
+ .Pp
175
+ A paragraph is simply one or more consecutive lines of text, separated
176
+ by one or more blank lines. (A blank line is any line that looks like a
177
+ blank line -- a line containing nothing but spaces or tabs is considered
178
+ blank.) Normal paragraphs should not be indented with spaces or tabs.
179
+ .Pp
180
+ The implication of the
181
+ .Qq one or more consecutive lines of text
182
+ rule is
183
+ that Markdown supports
184
+ .Qq hard-wrapped
185
+ Dtext paragraphs. This differs
186
+ significantly from most other text-to-HTML formatters (including Movable
187
+ Type's
188
+ .Qq Convert Line Breaks
189
+ option) which translate every line break
190
+ character in a paragraph into a `<br />` tag.
191
+ .Pp
192
+ When you *do* want to insert a `<br />` break tag using Markdown, you
193
+ end a line with two or more spaces, then type return.
194
+ .Pp
195
+ Yes, this takes a tad more effort to create a `<br />`, but a simplistic
196
+ "every line break is a `<br />`" rule wouldn't work for Markdown.
197
+ Markdown's email-style
198
+ .Sx blockquoting
199
+ and multi-paragraph
200
+ .Sx list items
201
+ work best -- and look better -- when you format them with hard breaks.
202
+ .Ss Headers
203
+ .Nm
204
+ supports two styles of headers,
205
+ .Em Setext
206
+ and
207
+ .Em atx .
208
+ .Pp
209
+ Setext-style headers are
210
+ .Sq underlined
211
+ using equal signs (for first-level
212
+ headers) and dashes (for second-level headers). For example:
213
+ .Bd -literal -offset indent
214
+ This is an H1
215
+ =============
216
+
217
+ This is an H2
218
+ -------------
219
+ .Ed
220
+ .Pp
221
+ Any number of underlining `=`'s or `-`'s will work.
222
+ .Pp
223
+ Atx-style headers use 1-6 hash characters at the start of the line,
224
+ corresponding to header levels 1-6. For example:
225
+ .Bd -literal -offset indent
226
+ # This is an H1
227
+
228
+ ## This is an H2
229
+
230
+ ###### This is an H6
231
+ .Ed
232
+ .Pp
233
+ Optionally, you may
234
+ .Qq close
235
+ atx-style headers. This is purely
236
+ cosmetic -- you can use this if you think it looks better. The
237
+ closing hashes don't even need to match the number of hashes
238
+ used to open the header. (The number of opening hashes
239
+ determines the header level.) :
240
+ .Bd -literal -offset indent
241
+ # This is an H1 #
242
+
243
+ ## This is an H2 ##
244
+
245
+ ### This is an H3 ######
246
+ .Ed
247
+ .Pp
248
+ .Ss Blockquotes
249
+ .Nm
250
+ uses email-style `>` characters for blockquoting. If you're
251
+ familiar with quoting passages of text in an email message, then you
252
+ know how to create a blockquote in Markdown. It looks best if you hard
253
+ wrap the text and put a `>` before every line:
254
+ .Bd -literal -offset indent
255
+ > This is a blockquote with two paragraphs. Lorem ipsum
256
+ > dolor sit amet, consectetuer adipiscing elit. Aliquam
257
+ > hendrerit mi posuere lectus. Vestibulum enim wisi,
258
+ > viverra nec, fringilla in, laoreet vitae, risus.
259
+ >
260
+ > Donec sit amet nisl. Aliquam semper ipsum sit amet
261
+ > velit. Suspendisse id sem consectetuer libero luctus
262
+ > adipiscing.
263
+ .Ed
264
+ .Pp
265
+ .Nm
266
+ allows you to be lazy and only put the `>` before the first
267
+ line of a hard-wrapped paragraph:
268
+ .Bd -literal -offset indent
269
+ > This is a blockquote with two paragraphs. Lorem ipsum
270
+ dolor sit amet, consectetuer adipiscing elit. Aliquam
271
+ hendrerit mi posuere lectus. Vestibulum enim wisi,
272
+ viverra nec, fringilla in, laoreet vitae, risus.
273
+
274
+ > Donec sit amet nisl. Aliquam semper ipsum sit amet
275
+ velit. Suspendisse id sem consectetuer libero luctus
276
+ adipiscing.
277
+ .Ed
278
+ .Pp
279
+ Blockquotes can be nested (i.e. a blockquote-in-a-blockquote) by
280
+ adding additional levels of `>`:
281
+ .Bd -literal -offset indent
282
+ > This is the first level of quoting.
283
+ >
284
+ > > This is nested blockquote.
285
+ >
286
+ > Back to the first level.
287
+ .Ed
288
+ .Pp
289
+ Blockquotes can contain other Markdown elements, including headers, lists,
290
+ and code blocks:
291
+ .Bd -literal -offset indent
292
+ > ## This is a header.
293
+ >
294
+ > 1. This is the first list item.
295
+ > 2. This is the second list item.
296
+ >
297
+ > Here's some example code:
298
+ >
299
+ > return shell_exec("echo $input | $markdown_script");
300
+ .Ed
301
+ .Pp
302
+ Any decent text editor should make email-style quoting easy. For
303
+ example, with BBEdit, you can make a selection and choose Increase
304
+ Quote Level from the Text menu.
305
+ .Ss Lists
306
+ .Nm
307
+ supports ordered (numbered) and unordered (bulleted) lists.
308
+ .Pp
309
+ Unordered lists use asterisks, pluses, and hyphens -- interchangably
310
+ \-- as list markers:
311
+ .Bd -literal -offset indent
312
+ * Red
313
+ * Green
314
+ * Blue
315
+ .Ed
316
+ .Pp
317
+ is equivalent to:
318
+ .Bd -literal -offset indent
319
+ + Red
320
+ + Green
321
+ + Blue
322
+ .Ed
323
+ .Pp
324
+ and:
325
+ .Bd -literal -offset indent
326
+ - Red
327
+ - Green
328
+ - Blue
329
+ .Ed
330
+ .Pp
331
+ Ordered lists use numbers followed by periods:
332
+ .Bd -literal -offset indent
333
+ 1. Bird
334
+ 2. McHale
335
+ 3. Parish
336
+ .Ed
337
+ .Pp
338
+ It's important to note that the actual numbers you use to mark the
339
+ list have no effect on the HTML output Markdown produces. The HTML
340
+ Markdown produces from the above list is:
341
+ .Bd -literal -offset indent
342
+ <ol>
343
+ <li>Bird</li>
344
+ <li>McHale</li>
345
+ <li>Parish</li>
346
+ </ol>
347
+ .Ed
348
+ .Pp
349
+ If you instead wrote the list in Markdown like this:
350
+ .Bd -literal -offset indent
351
+ 1. Bird
352
+ 1. McHale
353
+ 1. Parish
354
+ .Ed
355
+ .Pp
356
+ or even:
357
+ .Bd -literal -offset indent
358
+ 3. Bird
359
+ 1. McHale
360
+ 8. Parish
361
+ .Ed
362
+ .Pp
363
+ you'd get the exact same HTML output. The point is, if you want to,
364
+ you can use ordinal numbers in your ordered Markdown lists, so that
365
+ the numbers in your source match the numbers in your published HTML.
366
+ But if you want to be lazy, you don't have to.
367
+ .Pp
368
+ If you do use lazy list numbering, however, you should still start the
369
+ list with the number 1. At some point in the future, Markdown may support
370
+ starting ordered lists at an arbitrary number.
371
+ .Pp
372
+ List markers typically start at the left margin, but may be indented by
373
+ up to three spaces. List markers must be followed by one or more spaces
374
+ or a tab.
375
+ .Pp
376
+ To make lists look nice, you can wrap items with hanging indents:
377
+ .Bd -literal -offset indent
378
+ * Lorem ipsum dolor sit amet, consectetuer adipiscing
379
+ elit. Aliquam hendrerit mi posuere lectus. Vestibulum
380
+ enim wisi, viverra nec, fringilla in, laoreet vitae,
381
+ risus.
382
+ * Donec sit amet nisl. Aliquam semper ipsum sit amet
383
+ velit. Suspendisse id sem consectetuer libero luctus
384
+ adipiscing.
385
+ .Ed
386
+ .Pp
387
+ But if you want to be lazy, you don't have to:
388
+ .Bd -literal -offset indent
389
+ * Lorem ipsum dolor sit amet, consectetuer adipiscing
390
+ elit. Aliquam hendrerit mi posuere lectus. Vestibulum
391
+ enim wisi, viverra nec, fringilla in, laoreet vitae,
392
+ risus.
393
+ * Donec sit amet nisl. Aliquam semper ipsum sit amet
394
+ velit. Suspendisse id sem consectetuer libero luctus
395
+ adipiscing.
396
+ .Ed
397
+ .Pp
398
+ If list items are separated by blank lines, Markdown will wrap the
399
+ items in `<p>` tags in the HTML output. For example, this input:
400
+ .Bd -literal -offset indent
401
+ * Bird
402
+ * Magic
403
+ .Ed
404
+ .Pp
405
+ will turn into:
406
+ .Bd -literal -offset indent
407
+ <ul>
408
+ <li>Bird</li>
409
+ <li>Magic</li>
410
+ </ul>
411
+ .Ed
412
+ .Pp
413
+ But this:
414
+ .Bd -literal -offset indent
415
+ * Bird
416
+
417
+ * Magic
418
+ .Ed
419
+ .Pp
420
+ will turn into:
421
+ .Bd -literal -offset indent
422
+ <ul>
423
+ <li><p>Bird</p></li>
424
+ <li><p>Magic</p></li>
425
+ </ul>
426
+ .Ed
427
+ .Pp
428
+ List items may consist of multiple paragraphs. Each subsequent
429
+ paragraph in a list item must be intended by either 4 spaces
430
+ or one tab:
431
+ .Bd -literal -offset indent
432
+ 1. This is a list item with two paragraphs. Lorem ipsum
433
+ dolor sit amet, consectetuer adipiscing elit. Aliquam
434
+ hendrerit mi posuere lectus.
435
+
436
+ Vestibulum enim wisi, viverra nec, fringilla in,
437
+ laoreet vitae, risus. Donec sit amet nisl. Aliquam
438
+ semper ipsum sit amet velit.
439
+
440
+ 2. Suspendisse id sem consectetuer libero luctus
441
+ adipiscing.
442
+ .Ed
443
+ .Pp
444
+ It looks nice if you indent every line of the subsequent
445
+ paragraphs, but here again, Markdown will allow you to be
446
+ lazy:
447
+ .Bd -literal -offset indent
448
+ * This is a list item with two paragraphs.
449
+
450
+ This is the second paragraph in the list item.
451
+ You're only required to indent the first line. Lorem
452
+ ipsum dolor sit amet, consectetuer adipiscing elit.
453
+
454
+ * Another item in the same list.
455
+ .Ed
456
+ .Pp
457
+ To put a blockquote within a list item, the blockquote's `>`
458
+ delimiters need to be indented:
459
+ .Bd -literal -offset indent
460
+ * A list item with a blockquote:
461
+
462
+ > This is a blockquote
463
+ > inside a list item.
464
+ .Ed
465
+ .Pp
466
+ To put a code block within a list item, the code block needs
467
+ to be indented *twice* -- 8 spaces or two tabs:
468
+ .Bd -literal -offset indent
469
+ * A list item with a code block:
470
+
471
+ <code goes here>
472
+ .Ed
473
+ .Pp
474
+ It's worth noting that it's possible to trigger an ordered list by
475
+ accident, by writing something like this:
476
+ .Bd -literal -offset indent
477
+ 1986. What a great season.
478
+ .Ed
479
+ .Pp
480
+ In other words, a *number-period-space* sequence at the beginning of a
481
+ line. To avoid this, you can backslash-escape the period:
482
+ .Bd -literal -offset indent
483
+ 1986\\. What a great season.
484
+ .Ed
485
+ .Pp
486
+ .Ss Code Blocks
487
+ Pre-formatted code blocks are used for writing about programming or
488
+ markup source code. Rather than forming normal paragraphs, the lines
489
+ of a code block are interpreted literally. Markdown wraps a code block
490
+ in both `<pre>` and `<code>` tags.
491
+ .Pp
492
+ To produce a code block in Markdown, simply indent every line of the
493
+ block by at least 4 spaces or 1 tab. For example, given this input:
494
+ .Bd -literal -offset indent
495
+ This is a normal paragraph:
496
+
497
+ This is a code block.
498
+ .Ed
499
+ .Pp
500
+ .Nm
501
+ will generate:
502
+ .Bd -literal -offset indent
503
+ <p>This is a normal paragraph:</p>
504
+
505
+ <pre><code>This is a code block.
506
+ </code></pre>
507
+ .Ed
508
+ .Pp
509
+ One level of indentation -- 4 spaces or 1 tab -- is removed from each
510
+ line of the code block. For example, this:
511
+ .Bd -literal -offset indent
512
+ Here is an example of AppleScript:
513
+
514
+ tell application "Foo"
515
+ beep
516
+ end tell
517
+ .Ed
518
+ .Pp
519
+ will turn into:
520
+ .Bd -literal -offset indent
521
+ <p>Here is an example of AppleScript:</p>
522
+
523
+ <pre><code>tell application "Foo"
524
+ beep
525
+ end tell
526
+ </code></pre>
527
+ .Ed
528
+ .Pp
529
+ A code block continues until it reaches a line that is not indented
530
+ (or the end of the article).
531
+ .Pp
532
+ Within a code block, ampersands (`&`) and angle brackets (`<` and `>`)
533
+ are automatically converted into HTML entities. This makes it very
534
+ easy to include example HTML source code using Markdown -- just paste
535
+ it and indent it, and Markdown will handle the hassle of encoding the
536
+ ampersands and angle brackets. For example, this:
537
+ .Bd -literal -offset indent
538
+ <div class="footer">
539
+ &copy; 2004 Foo Corporation
540
+ </div>
541
+ .Ed
542
+ .Pp
543
+ will turn into:
544
+ .Bd -literal -offset indent
545
+ <pre><code>&lt;div class="footer"&gt;
546
+ &amp;copy; 2004 Foo Corporation
547
+ &lt;/div&gt;
548
+ </code></pre>
549
+ .Ed
550
+ .Pp
551
+ Regular Markdown syntax is not processed within code blocks. E.g.,
552
+ asterisks are just literal asterisks within a code block. This means
553
+ it's also easy to use Markdown to write about Markdown's own syntax.
554
+ .Ss Horizontal Rules
555
+ You can produce a horizontal rule tag (`<hr />`) by placing three or
556
+ more hyphens, asterisks, or underscores on a line by themselves. If you
557
+ wish, you may use spaces between the hyphens or asterisks. Each of the
558
+ following lines will produce a horizontal rule:
559
+ .Bd -literal -offset indent
560
+ * * *
561
+
562
+ ***
563
+
564
+ *****
565
+
566
+ - - -
567
+
568
+ ---------------------------------------
569
+ .Ed
570
+ .Pp
571
+ .Sh Span Elements
572
+ .Ss Links
573
+ .Nm
574
+ supports two style of links:
575
+ .Em inline
576
+ and
577
+ .Em reference .
578
+ .Pp
579
+ In both styles, the link text is delimited by [square brackets].
580
+ .Pp
581
+ To create an inline link, use a set of regular parentheses immediately
582
+ after the link text's closing square bracket. Inside the parentheses,
583
+ put the URL where you want the link to point, along with an *optional*
584
+ title for the link, surrounded in quotes. For example:
585
+ .Bd -literal -offset indent
586
+ This is [an example](http://example.com/ "Title") inline link.
587
+
588
+ [This link](http://example.net/) has no title attribute.
589
+ .Ed
590
+ .Pp
591
+ Will produce:
592
+ .Bd -literal -offset indent
593
+ <p>This is <a href="http://example.com/" title="Title">
594
+ an example</a> inline link.</p>
595
+
596
+ <p><a href="http://example.net/">This link</a> has no
597
+ title attribute.</p>
598
+ .Ed
599
+ .Pp
600
+ If you're referring to a local resource on the same server, you can
601
+ use relative paths:
602
+ .Bd -literal -offset indent
603
+ See my [About](/about/) page for details.
604
+ .Ed
605
+ .Pp
606
+ Reference-style links use a second set of square brackets, inside
607
+ which you place a label of your choosing to identify the link:
608
+ .Bd -literal -offset indent
609
+ This is [an example][id] reference-style link.
610
+ .Ed
611
+ .Pp
612
+ You can optionally use a space to separate the sets of brackets:
613
+ .Bd -literal -offset indent
614
+ This is [an example] [id] reference-style link.
615
+ .Ed
616
+ .Pp
617
+ Then, anywhere in the document, you define your link label like this,
618
+ on a line by itself:
619
+ .Bd -literal -offset indent
620
+ [id]: http://example.com/ "Optional Title Here"
621
+ .Ed
622
+ .Pp
623
+ That is:
624
+ .Bl -bullet
625
+ .It
626
+ Square brackets containing the link identifier (optionally
627
+ indented from the left margin using up to three spaces);
628
+ .It
629
+ followed by a colon;
630
+ .It
631
+ followed by one or more spaces (or tabs);
632
+ .It
633
+ followed by the URL for the link;
634
+ .It
635
+ optionally followed by a title attribute for the link, enclosed
636
+ in double or single quotes, or enclosed in parentheses.
637
+ .El
638
+ .Pp
639
+ The following three link definitions are equivalent:
640
+ .Bd -literal -offset indent
641
+ [foo]: http://example.com/ "Optional Title Here"
642
+ [foo]: http://example.com/ 'Optional Title Here'
643
+ [foo]: http://example.com/ (Optional Title Here)
644
+ .Ed
645
+ .Pp
646
+ .Em Note :
647
+ There is a known bug in Markdown.pl 1.0.1 which prevents
648
+ single quotes from being used to delimit link titles.
649
+ .Pp
650
+ The link URL may, optionally, be surrounded by angle brackets:
651
+ .Bd -literal -offset indent
652
+ [id]: <http://example.com/> "Optional Title Here"
653
+ .Ed
654
+ .Pp
655
+ You can put the title attribute on the next line and use extra spaces
656
+ or tabs for padding, which tends to look better with longer URLs:
657
+ .Bd -literal -offset indent
658
+ [id]: http://example.com/longish/path/to/resource/here
659
+ "Optional Title Here"
660
+ .Ed
661
+ .Pp
662
+ Link definitions are only used for creating links during Markdown
663
+ processing, and are stripped from your document in the HTML output.
664
+ .Pp
665
+ Link definition names may constist of letters, numbers, spaces, and
666
+ punctuation -- but they are
667
+ .Em not
668
+ case sensitive. E.g. these two
669
+ links:
670
+ .Bd -literal -offset indent
671
+ [link text][a]
672
+ [link text][A]
673
+ .Ed
674
+ .Pp
675
+ are equivalent.
676
+ .Pp
677
+ The
678
+ .Em implicit link name
679
+ shortcut allows you to omit the name of the
680
+ link, in which case the link text itself is used as the name.
681
+ Just use an empty set of square brackets -- e.g., to link the word
682
+ .Qq Google
683
+ to the google.com web site, you could simply write:
684
+ .Bd -literal -offset indent
685
+ [Google][]
686
+ .Ed
687
+ .Pp
688
+ And then define the link:
689
+ .Bd -literal -offset indent
690
+ [Google]: http://google.com/
691
+ .Ed
692
+ .Pp
693
+ Because link names may contain spaces, this shortcut even works for
694
+ multiple words in the link text:
695
+ .Bd -literal -offset indent
696
+ Visit [Daring Fireball][] for more information.
697
+ .Ed
698
+ .Pp
699
+ And then define the link:
700
+ .Bd -literal -offset indent
701
+ [Daring Fireball]: http://daringfireball.net/
702
+ .Ed
703
+ .Pp
704
+ Link definitions can be placed anywhere in your Markdown document. I
705
+ tend to put them immediately after each paragraph in which they're
706
+ used, but if you want, you can put them all at the end of your
707
+ document, sort of like footnotes.
708
+ .Pp
709
+ Here's an example of reference links in action:
710
+ .Bd -literal -offset indent
711
+ I get 10 times more traffic from [Google] [1] than from
712
+ [Yahoo] [2] or [MSN] [3].
713
+
714
+ [1]: http://google.com/ "Google"
715
+ [2]: http://search.yahoo.com/ "Yahoo Search"
716
+ [3]: http://search.msn.com/ "MSN Search"
717
+ .Ed
718
+ .Pp
719
+ Using the implicit link name shortcut, you could instead write:
720
+ .Bd -literal -offset indent
721
+ I get 10 times more traffic from [Google][] than from
722
+ [Yahoo][] or [MSN][].
723
+
724
+ [google]: http://google.com/ "Google"
725
+ [yahoo]: http://search.yahoo.com/ "Yahoo Search"
726
+ [msn]: http://search.msn.com/ "MSN Search"
727
+ .Ed
728
+ .Pp
729
+ Both of the above examples will produce the following HTML output:
730
+ .Bd -literal -offset indent
731
+ <p>I get 10 times more traffic from <a href="http://google.com/"
732
+ title="Google">Google</a> than from
733
+ <a href="http://search.yahoo.com/" title="Yahoo Search">Yahoo</a>
734
+ or
735
+ <a href="http://search.msn.com/" title="MSN Search">MSN</a>.</p>
736
+ .Ed
737
+ .Pp
738
+ For comparison, here is the same paragraph written using
739
+ Markdown's inline link style:
740
+ .Bd -literal -offset indent
741
+ I get 10 times more traffic from
742
+ [Google](http://google.com/ "Google") than from
743
+ [Yahoo](http://search.yahoo.com/ "Yahoo Search") or
744
+ [MSN](http://search.msn.com/ "MSN Search").
745
+ .Ed
746
+ .Pp
747
+ The point of reference-style links is not that they're easier to
748
+ write. The point is that with reference-style links, your document
749
+ source is vastly more readable. Compare the above examples: using
750
+ reference-style links, the paragraph itself is only 81 characters
751
+ long; with inline-style links, it's 176 characters; and as raw HTML,
752
+ it's 234 characters. In the raw HTML, there's more markup than there
753
+ is text.
754
+ .Pp
755
+ With Markdown's reference-style links, a source document much more
756
+ closely resembles the final output, as rendered in a browser. By
757
+ allowing you to move the markup-related metadata out of the paragraph,
758
+ you can add links without interrupting the narrative flow of your
759
+ prose.
760
+ .Ss Emphasis
761
+ Markdown treats asterisks (`*`) and underscores (`_`) as indicators of
762
+ emphasis. Text wrapped with one `*` or `_` will be wrapped with an
763
+ HTML `<em>` tag; double `*`'s or `_`'s will be wrapped with an HTML
764
+ `<strong>` tag. E.g., this input:
765
+ .Bd -literal -offset indent
766
+ *single asterisks*
767
+
768
+ _single underscores_
769
+
770
+ **double asterisks**
771
+
772
+ __double underscores__
773
+ .Ed
774
+ .Pp
775
+ will produce:
776
+ .Bd -literal -offset indent
777
+ <em>single asterisks</em>
778
+
779
+ <em>single underscores</em>
780
+
781
+ <strong>double asterisks</strong>
782
+
783
+ <strong>double underscores</strong>
784
+ .Ed
785
+ .Pp
786
+ You can use whichever style you prefer; the lone restriction is that
787
+ the same character must be used to open and close an emphasis span.
788
+ .Pp
789
+ Emphasis can be used in the middle of a word:
790
+ .Bd -literal -offset indent
791
+ un*fucking*believable
792
+ .Ed
793
+ .Pp
794
+ But if you surround an `*` or `_` with spaces, it'll be treated as a
795
+ literal asterisk or underscore.
796
+ .Pp
797
+ To produce a literal asterisk or underscore at a position where it
798
+ would otherwise be used as an emphasis delimiter, you can backslash
799
+ escape it:
800
+ .Bd -literal -offset indent
801
+ \\*this text is surrounded by literal asterisks\\*
802
+ .Ed
803
+ .Pp
804
+ .Ss Code
805
+ To indicate a span of code, wrap it with backtick quotes (`` ` ``).
806
+ Unlike a pre-formatted code block, a code span indicates code within a
807
+ normal paragraph. For example:
808
+ .Bd -literal -offset indent
809
+ Use the `printf()` function.
810
+ .Ed
811
+ .Pp
812
+ will produce:
813
+ .Bd -literal -offset indent
814
+ <p>Use the <code>printf()</code> function.</p>
815
+ .Ed
816
+ .Pp
817
+ To include a literal backtick character within a code span, you can use
818
+ multiple backticks as the opening and closing delimiters:
819
+ .Bd -literal -offset indent
820
+ ``There is a literal backtick (`) here.``
821
+ .Ed
822
+ .Pp
823
+ which will produce this:
824
+ .Bd -literal -offset indent
825
+ <p><code>There is a literal backtick (`) here.</code></p>
826
+ .Ed
827
+ .Pp
828
+ The backtick delimiters surrounding a code span may include spaces --
829
+ one after the opening, one before the closing. This allows you to place
830
+ literal backtick characters at the beginning or end of a code span:
831
+ .Bd -literal -offset indent
832
+ A single backtick in a code span: `` ` ``
833
+
834
+ A backtick-delimited string in a code span: `` `foo` ``
835
+ .Ed
836
+ .Pp
837
+ will produce:
838
+ .Bd -literal -offset indent
839
+ <p>A single backtick in a code span: <code>`</code></p>
840
+
841
+ <p>A backtick-delimited string in a code span: <code>`foo`</code></p>
842
+ .Ed
843
+ .Pp
844
+ With a code span, ampersands and angle brackets are encoded as HTML
845
+ entities automatically, which makes it easy to include example HTML
846
+ tags. Markdown will turn this:
847
+ .Bd -literal -offset indent
848
+ Please don't use any `<blink>` tags.
849
+ .Ed
850
+ .Pp
851
+ into:
852
+ .Bd -literal -offset indent
853
+ <p>Please don't use any <code>&lt;blink&gt;</code> tags.</p>
854
+ .Ed
855
+ .Pp
856
+ You can write this:
857
+ .Bd -literal -offset indent
858
+ `&#8212;` is the decimal-encoded equivalent of `&mdash;`.
859
+ .Ed
860
+ .Pp
861
+ to produce:
862
+ .Bd -literal -offset indent
863
+ <p><code>&amp;#8212;</code> is the decimal-encoded
864
+ equivalent of <code>&amp;mdash;</code>.</p>
865
+ .Ed
866
+ .Pp
867
+ .Ss Images
868
+ Admittedly, it's fairly difficult to devise a
869
+ .Qq natural
870
+ syntax for placing images into a plain text document format.
871
+ .Pp
872
+ Markdown uses an image syntax that is intended to resemble the syntax
873
+ for links, allowing for two styles:
874
+ .Em inline
875
+ and
876
+ .Em reference .
877
+ .Pp
878
+ Inline image syntax looks like this:
879
+ .Bd -literal -offset indent
880
+ ![Alt text](/path/to/img.jpg)
881
+
882
+ ![Alt text](/path/to/img.jpg =Optional size "Optional title")
883
+ .Ed
884
+ .Pp
885
+ That is:
886
+ .Bl -bullet
887
+ .It
888
+ An exclamation mark: `!`;
889
+ .It
890
+ followed by a set of square brackets, containing the `alt`
891
+ attribute text for the image;
892
+ .It
893
+ followed by a set of parentheses, containing the URL or path to
894
+ the image, an optional `size` attribute (in
895
+ .Ar width Li c Ar height
896
+ format) prefixed with a `=`,
897
+ and an optional `title` attribute enclosed in double
898
+ or single quotes.
899
+ .El
900
+ .Pp
901
+ Reference-style image syntax looks like this:
902
+ .Bd -literal -offset indent
903
+ ![Alt text][id]
904
+ .Ed
905
+ .Pp
906
+ Where
907
+ .Qq id
908
+ is the name of a defined image reference. Image references
909
+ are defined using syntax identical to link references:
910
+ .Bd -literal -offset indent
911
+ [id]: url/to/image =Optional size "Optional title attribute"
912
+ .Ed
913
+ .Pp
914
+ .Sh Miscellaneous
915
+ .Ss Automatic Links
916
+ .Nm
917
+ supports a shortcut style for creating
918
+ .Qq automatic
919
+ links for URLs and email addresses: simply surround the URL or email
920
+ address with angle brackets. What this means is that if you want to
921
+ show the actual text of a URL or email address, and also have it be
922
+ a clickable link, you can do this:
923
+ .Bd -literal -offset indent
924
+ <http://example.com/>
925
+ .Ed
926
+ .Pp
927
+ .Nm
928
+ will turn this into:
929
+ .Bd -literal -offset indent
930
+ <a href="http://example.com/">http://example.com/</a>
931
+ .Ed
932
+ .Pp
933
+ Automatic links for email addresses work similarly, except that
934
+ Markdown will also perform a bit of randomized decimal and hex
935
+ entity-encoding to help obscure your address from address-harvesting
936
+ spambots. For example, Markdown will turn this:
937
+ .Bd -literal -offset indent
938
+ <address@example.com>
939
+ .Ed
940
+ .Pp
941
+ into something like this:
942
+ .Bd -literal -offset indent
943
+ <a href="&#x6D;&#x61;i&#x6C;&#x74;&#x6F;:&#x61;&#x64;&#x64;&#x72;&#x65;
944
+ &#115;&#115;&#64;&#101;&#120;&#x61;&#109;&#x70;&#x6C;e&#x2E;&#99;&#111;
945
+ &#109;">&#x61;&#x64;&#x64;&#x72;&#x65;&#115;&#115;&#64;&#101;&#120;&#x61;
946
+ &#109;&#x70;&#x6C;e&#x2E;&#99;&#111;&#109;</a>
947
+ .Ed
948
+ .Pp
949
+ which will render in a browser as a clickable link to
950
+ .Qq address@example.com .
951
+ .Pp
952
+ (This sort of entity-encoding trick will indeed fool many, if not
953
+ most, address-harvesting bots, but it definitely won't fool all of
954
+ them. It's better than nothing, but an address published in this way
955
+ will probably eventually start receiving spam.)
956
+ .Ss Backslash Escapes
957
+ .Nm
958
+ allows you to use backslash escapes to generate literal
959
+ characters which would otherwise have special meaning in Markdown's
960
+ formatting syntax. For example, if you wanted to surround a word with
961
+ literal asterisks (instead of an HTML `<em>` tag), you add backslashes
962
+ before the asterisks, like this:
963
+ .Bd -literal -offset indent
964
+ \\*literal asterisks\\*
965
+ .Ed
966
+ .Pp
967
+ .Nm
968
+ provides backslash escapes for the following characters:
969
+ .Bl -tag -compact
970
+ .It \&\
971
+ backslash
972
+ .It \`
973
+ backtick
974
+ .It *
975
+ asterisk
976
+ .It _
977
+ underscore
978
+ .It \{\}
979
+ curly braces
980
+ .It []
981
+ square brackets
982
+ .It ()
983
+ parentheses
984
+ .It #
985
+ hash mark
986
+ .It +
987
+ plus sign
988
+ .It \-
989
+ minus sign (hyphen)
990
+ .It \.
991
+ dot
992
+ .It \!
993
+ exclamation mark
994
+ .El
995
+ .Sh BUGS
996
+ .Nm
997
+ assumes that tabs are set to 4 spaces.
998
+ .Sh AUTHOR
999
+ John Gruber
1000
+ .%T http://daringfireball.net/
1001
+ .Sh SEE ALSO
1002
+ .Xr markdown 1 ,
1003
+ .Xr markdown 3 ,
1004
+ .Xr mkd-callbacks 3 ,
1005
+ .Xr mkd-functions 3 ,
1006
+ .Xr mkd-extensions 7 .
1007
+ .Pp
1008
+ .%T http://daringfireball.net/projects/markdown
1009
+ .br
1010
+ .%T http://docutils.sourceforge.net/mirror/setext.html
1011
+ .br
1012
+ .%T http://www.aaronsw.com/2002/atx/
1013
+ .br
1014
+ .%T http://textism.com/tools/textile/
1015
+ .br
1016
+ .%T http://docutils.sourceforge.net/rst.html
1017
+ .br
1018
+ .%T http://www.triptico.com/software/grutatxt.html
1019
+ .br
1020
+ .%T http://ettext.taint.org/doc/
data/man/rdiscount.1 ADDED
@@ -0,0 +1,23 @@
1
+ .\" generated with Ronn/v0.5
2
+ .\" http://github.com/rtomayko/ronn/
3
+ .
4
+ .TH "RDISCOUNT" "1" "April 2010" "" "RUBY"
5
+ .
6
+ .SH "NAME"
7
+ \fBrdiscount\fR \-\- humane markup to HTML conversion tool
8
+ .
9
+ .SH "SYNOPSIS"
10
+ \fBrdiscount\fR [\fIfile\fR...]
11
+ .
12
+ .SH "DESCRIPTION"
13
+ The \fBrdiscount\fR utility reads one or more markdown(7)\-formatted text \fIfile\fRs and
14
+ writes HTML to standard output. With no \fIfile\fR, or when \fIfile\fR is '\-', \fBrdiscount\fR reads source text from standard input.
15
+ .
16
+ .SH "RETURN VALUES"
17
+ The \fBrdiscount\fR utility exits 0 on success, and > 0 if an error occurs.
18
+ .
19
+ .SH "SEE ALSO"
20
+ markdown(7)
21
+ .
22
+ .SH "AUTHOR"
23
+ Ryan Tomayko \fIhttp://tomayko.com/about\fR
@@ -0,0 +1,24 @@
1
+ rdiscount(1) -- humane markup to HTML conversion tool
2
+ =====================================================
3
+
4
+ ## SYNOPSIS
5
+
6
+ `rdiscount` [<file>...]
7
+
8
+ ## DESCRIPTION
9
+
10
+ The `rdiscount` utility reads one or more markdown(7)-formatted text <file>s and
11
+ writes HTML to standard output. With no <file>, or when <file> is '-',
12
+ `rdiscount` reads source text from standard input.
13
+
14
+ ## RETURN VALUES
15
+
16
+ The `rdiscount` utility exits 0 on success, and > 0 if an error occurs.
17
+
18
+ ## SEE ALSO
19
+
20
+ markdown(7)
21
+
22
+ ## AUTHOR
23
+
24
+ Ryan Tomayko <http://tomayko.com/about>
data/rdiscount.gemspec CHANGED
@@ -1,8 +1,8 @@
1
1
  Gem::Specification.new do |s|
2
2
  s.name = 'rdiscount'
3
- s.version = '1.6.3.1'
3
+ s.version = '1.6.3.2'
4
4
  s.summary = "Fast Implementation of Gruber's Markdown in C"
5
- s.date = '2010-04-20'
5
+ s.date = '2010-05-14'
6
6
  s.email = 'r@tomayko.com'
7
7
  s.homepage = 'http://github.com/rtomayko/rdiscount'
8
8
  s.has_rdoc = true
@@ -34,6 +34,9 @@ Gem::Specification.new do |s|
34
34
  ext/xml.c
35
35
  lib/markdown.rb
36
36
  lib/rdiscount.rb
37
+ man/markdown.7
38
+ man/rdiscount.1
39
+ man/rdiscount.1.ronn
37
40
  rdiscount.gemspec
38
41
  test/benchmark.rb
39
42
  test/benchmark.txt
metadata CHANGED
@@ -6,8 +6,8 @@ version: !ruby/object:Gem::Version
6
6
  - 1
7
7
  - 6
8
8
  - 3
9
- - 1
10
- version: 1.6.3.1
9
+ - 2
10
+ version: 1.6.3.2
11
11
  platform: ruby
12
12
  authors:
13
13
  - Ryan Tomayko
@@ -17,7 +17,7 @@ autorequire:
17
17
  bindir: bin
18
18
  cert_chain: []
19
19
 
20
- date: 2010-04-20 00:00:00 -07:00
20
+ date: 2010-05-14 00:00:00 -07:00
21
21
  default_executable:
22
22
  dependencies: []
23
23
 
@@ -55,6 +55,9 @@ files:
55
55
  - ext/xml.c
56
56
  - lib/markdown.rb
57
57
  - lib/rdiscount.rb
58
+ - man/markdown.7
59
+ - man/rdiscount.1
60
+ - man/rdiscount.1.ronn
58
61
  - rdiscount.gemspec
59
62
  - test/benchmark.rb
60
63
  - test/benchmark.txt