default_markdown.cr 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199
  1. DEFAULT_MARKDOWN = %q{
  2. # Luce
  3. Luce is a CommonMark compliant parser and renderer which supports a few
  4. common extensions.
  5. Luce is a port of the [Dart markdown package].
  6. ## Installation
  7. 1. Add the dependency to your `shard.yml`:
  8. ```yaml
  9. dependencies:
  10. luce:
  11. git: https://codeberg.org/supercell/luce
  12. version: ~> 0.5.0
  13. ```
  14. 2. Run `shards install`
  15. ## Usage
  16. ```crystal
  17. require "luce"
  18. puts Luce.to_html("Hello *Markdown*") # => <p>Hello <em>Markdown</em></p>
  19. ```
  20. ## Syntax extensions
  21. A few Markdown extensions, beyond what was specified in the original
  22. [Perl Markdown] implementation, are supported. By default, the ones
  23. supported in [CommonMark] are enabled. Any individual extension can
  24. be enabled by specifying an Array of extension syntax in the
  25. `block_syntaxes` or `inline_syntaxes` argument of `Luce.to_html`.
  26. The currently supported inline extension syntax are:
  27. * `InlineHTMLSyntax.new()` - approximately CommonMark's
  28. [definition][CommonMark-raw-html] of "Raw HTML".
  29. The currently supported block extension syntax are:
  30. * `FencedCodeBlockSyntax` - Code blocks familiar to Pandoc and PHP
  31. Markdown Extra users.
  32. * `HeaderWithIdSyntax` - ATX-style headers have generated IDs, for link
  33. anchors (akin to Pandoc's [auto_identifiers]).
  34. * `SetextHeaderWithIdSyntax` - Setext-style headers have generated IDs
  35. for link anchors (akin to Pandoc's [auto_identifiers]).
  36. * `TableSyntax` - Table syntax familiar to GitHub, PHP Markdown Extra,
  37. and Pandoc users.
  38. For example:
  39. ```crystal
  40. html = Luce.to_html(%(Hello <span class="green">Markdown</span>),
  41. inline_syntaxes: [Luce::InlineHTMLSyntax.new])
  42. puts html # => <p>Hello <span class="green">Markdown</span></p>\n
  43. ```
  44. ## Extension Sets
  45. To make extension management easy, you can also just specify an
  46. extension set. Both `Luce.to_html` and `Document.new` accept an
  47. `extension_set` named parameter. Currently, there are four pre-defined
  48. extension sets.
  49. * `Luce::ExtensionSet::NONE` includes no extensions. With no
  50. extensions, Markdown documents will be parsed with a default set of
  51. block and inline syntax parsers that closely match how the document
  52. might be parsed by the original [Perl Markdown] implementation.
  53. * `Luce::ExtensionSet::COMMON_MARK` includes two extensions in addition
  54. to the default parsers to bring the parsed output closer to the
  55. [CommonMark] specification:
  56. * Block Syntax Parser
  57. * `FencedCodeBlockSyntax`
  58. * Inline Syntax Parser
  59. * `InlineHTMLSyntax`
  60. * `Luce::ExtensionSet::GITHUB_FLAVOURED` includes five extensions in
  61. addition to the default parsers to bring the parsed output close to the
  62. [GitHub Flavoured] Markdown specification:
  63. * Block Syntax Parser
  64. * `FencedCodeBlockSyntax`
  65. * `TableSyntax`
  66. * Inline Syntax Parser
  67. * `InlineHTMLSyntax`
  68. * `StrikethroughSyntax`
  69. * `AutolinkExtensionSyntax`
  70. * `Luce::ExtensionSet::GITHUB_WEB` includes eight extensions. The same
  71. set of parsers used int he `GITHUB_FLAVOURED` extension set with the
  72. addition of the block syntax parsers, HeaderWithIdSyntax and
  73. SetextHeaderWithIdSyntax, which add `id` attributes to headers and
  74. inline syntax parser, EmojiSyntax, for parsing GitHub style emoji
  75. characters:
  76. * Block Syntax Parser
  77. * `FencedCodeBlockSyntax`
  78. * `HeaderWithIdSyntax`, which adds `id` attributes to ATX-style
  79. headers, for easy intra-document linking.
  80. * `SetextHeaderWithIdSyntax`, which adds `id` attributes to
  81. Setext-style headers, for easy intra-document linking.
  82. * `TableSyntax`
  83. * Inline Syntax Parser
  84. * `InlineHTMLSyntax`
  85. * `StrikethroguhSyntax`
  86. * `EmojiSyntax`
  87. * `AutolinkExtension`
  88. ## Custom syntax extensions
  89. You can create and use your own syntax.
  90. ```crystal
  91. require "luce"
  92. syntaxes = [Luce::TextSyntax.new("nyan", sub: "~=[,,_,,]:3")]
  93. puts Luce.to_html("nyan", inline_syntaxes: syntaxes)
  94. # => <p>~=[,,_,,]:3</p>
  95. ```
  96. ## HTML sanitization
  97. This shard offers no features in the way of HTML sanitization.
  98. Read Estevão Soares dos Santos' great article,
  99. ["Markdown's XSS Vulnerability (and how to mitigate it)"](https://github.com/showdownjs/showdown/wiki/Markdown%27s-XSS-Vulnerability-(and-how-to-mitigate-it)),
  100. to learn more.
  101. The authors recommend that you perform any necessary sanitization on the
  102. resulting HTML, for example via the [`sanitize` shard].
  103. ## Contributing
  104. 1. Fork it (<https://codeberg.org/repo/fork/21123>)
  105. 2. Create your feature branch (`git checkout -b my-new-feature`)
  106. 3. Commit your changes (`git commit -am 'Add some feature'`)
  107. 4. Push to the branch (`git push origin my-new-feature`)
  108. 5. Create a new Pull Request
  109. ### CommonMark compliance
  110. This shard contains a number of files in the `tools` directory for tracking
  111. compliance with [CommonMark].
  112. #### Updating the CommonMark stats when changing the implementation
  113. 1. Update the shard and test code, making sure that tests still pass.
  114. 2. Run `crystal tools/stats.cr --update-files` to update the per-test
  115. results `tools/common_mark_stats.json` and the test summary
  116. `tools/common_mark_stats.txt`.
  117. 3. Verify that more tests now pass - or at least, no more tests fail.
  118. 4. Make sure you include the updated stats files in your commit.
  119. #### Updating the CommonMark test file for a spec update
  120. 1. Check out the [CommonMark source]. Make sure you checkout a *major* release.
  121. 2. Dump the test output overwriting the existing tests file.
  122. ```console
  123. > cd /path/to/commonmark-spec
  124. > python3 test/spec_tests.py --dump-tests > \
  125. /path/to/luce/tools/common_mark_tests.json
  126. ```
  127. 3. Update the stats files as described above. Note any changes in the results.
  128. 4. Update any references to the existing spec by searching for
  129. `https://spec.commonmark.org/0.30` in the repository. (Including this one.)
  130. Verify the updated links are still valid.
  131. 5. Commit changes, including a corresponding note in `CHANGELOG.md`.
  132. ## Contributors
  133. - [supercell](https://codeberg.org/supercell) - creator and maintainer
  134. [Dart Markdown package]: https://pub.dev/packages/markdown
  135. [Perl Markdown]: https://daringfireball.net/projects/markdown/
  136. [CommonMark]: https://commonmark.org/
  137. [CommonMark-raw-html]: https://spec.commonmark.org/0.30/#raw-html
  138. [CommonMark source]: https://github.com/commonmark/commonmark-spec
  139. [GitHub Flavoured]: https://github.github.io/gfm/
  140. [auto_identifiers]: https://pandoc.org/MANUAL.html#extension-auto_identifiers
  141. [`sanitize` shard]: https://shardbox.org/shards/sanitize
  142. }