# Documentation
-Every new feature must be documented under in the [README.md](README.md). Documentation must be written in [GFM](https://help.github.com/articles/github-flavored-markdown) since Github itself is the primary to HTML converter used. In particular, remember that GFM adds line breaks at single newlines, so just forget about the 70 characters wide rule.
+Every new feature must be documented under in the [README.md](README.md). Documentation must be written in [GFM](https://help.github.com/articles/github-flavored-markdown) since GitHub itself is the primary to HTML converter used. In particular, remember that GFM adds line breaks at single newlines, so just forget about the 70 characters wide rule.
# Markdown Flavors
Next, if there are many more than one Jekyll feature options, create a `g:vim_markdown_jekyll` option that turns them all on at once.
-# Tests
-
-All new features must have tests. While we don't require unit tests, which are too hard to do in certain cases, you should create a test under the `test/` directory with a predictable name which allows other users to quickly test your feature. Good tests should explain their expected input / output behavior. Failing test should be marked with `FAIL` somewhere near the test, possibly explaining why it fails. For example:
-
-```
-## Links
+# Style
-[Link text](link URL)
+When choosing between multiple valid Markdown syntaxes, the default behavior must be that specified at: <http://www.cirosantilli.com/markdown-styleguide>
-... more correct link tests ...
+If you wish to have a behavior that differs from that style guide, add an option to turn it on or off, and leave it off by default.
-###### FAIL: should not be highlighted as a link
-
-Text (with parenthesis) alone should not be highlighted as a link. (Issue #57)
-
-... more failed link tests ...
+# Tests
-## Code Blocks
-```
+All new features must have unit tests.
projects / etc / vim.git / blobdiff