git.iko.soy/typeable/pandoc
on free help sign in
typeable/pandoc/CONTRIBUTING.md
289 lines 12 kB history raw
1Contributing to pandoc
2======================
4Found a bug?
5------------
7Bug reports are welcome! Please report all bugs on pandoc's github
8[issue tracker].
10Before you submit a bug report, search the (open *and* closed) issues to make
11sure the issue hasn't come up before. Also, check the [User's Guide] and [FAQs]
12for anything relevant.
14Make sure you can reproduce the bug with the latest released version of pandoc
15(or, even better, the development version).
17Your report should give detailed instructions for how to reproduce the problem,
18including
20 * the exact command line used
21 * the exact input used
22 * the output received
23 * the output you expected instead
25A small test case (just a few lines) is ideal. If your input is large,
26try to whittle it down to the minimum necessary to illustrate the problem.
28Out of scope?
29-------------
31A less than perfect conversion does not necessarily mean there's
32a bug in pandoc. Quoting from the MANUAL:
34> Because Pandoc's intermediate representation of a document is less
35> expressive than many of the formats it converts between, one should
36> not expect perfect conversions between every format and every other.
37> Pandoc attempts to preserve the structural elements of a document, but
38> not formatting details such as margin size. And some document elements,
39> such as complex tables, may not fit into Pandoc's simple document
40> model. While conversions from Pandoc's Markdown to all formats aspire
41> to be perfect, conversions from formats more expressive than Pandoc's
42> Markdown can be expected to be lossy.
44For example, both docx and odt can represent margin size, but because
45pandoc's internal document model does not contain a representation of
46margin size, this information will be lost on converting from docx
47to odt. (You can, however, customize margin size using `--reference-odt`.)
49So before submitting a bug report, consider whether it might be
50"out of scope." If it concerns a feature of documents that isn't
51representable in pandoc's Markdown, then it very likely is.
52(If in doubt, you can always ask on pandoc-discuss.)
54Fixing bugs from the issue tracker
55----------------------------------
57Almost all the bugs on the issue tracker have one or more associated
58tags. These are used to indicate the *difficulty* and *nature* of a
59bug. There is not yet a way to indicate priority. An up to date
60summary of issues can be found [here](https://github.com/jgm/pandoc/labels).
62* [enhancement] -- A feature which would be desirable. We recommend
63 you discuss any proposed enhancement on pandoc-discuss before
64 writing code.
65* [bug] -- A problem which needs to be fixed.
66* [minor] -- The fix should only be a couple of lines.
67* [major] -- The fix might require structural changes or in depth knowledge of
68the code base.
69* [reader] -- A request to add a new input format.
70* [writer] -- A request to add a new output format.
71* [docs] -- A discrepency or ambiguity in the documentation.
72* [inprogress] -- Someone is actively working on or planning to work on the
73 ticket.
74* [more discussion needed] -- It is unclear what the correct approach
75 to solving the ticket is. Before starting on tickets such as this it
76 would be advisable to post on the ticket.
77* [more info needed] -- We require more information from a user before
78 we can classify a report properly.
80Have an idea for a new feature?
81-------------------------------
83First, search [pandoc-discuss] and the issue tracker (both open and closed
84issues) to make sure that the idea has not been discussed before.
86Explain the rationale for the feature you're requesting. Why would this
87feature be useful? Consider also any possible drawbacks, including backwards
88compatibility, new library dependencies, and performance issues.
90It is best to discuss a potential new feature on [pandoc-discuss]
91before opening an issue.
93Patches and pull requests
94-------------------------
96Patches and pull requests are welcome. Before you put time into a nontrivial
97patch, it is a good idea to discuss it on [pandoc-discuss], especially if it is
98for a new feature (rather than fixing a bug).
100Please follow these guidelines:
1021. Each patch (commit) should make a single logical change (fix a bug, add
103 a feature, clean up some code, add documentation). Everything
104 related to that change should be included (including tests and
105 documentation), and nothing unrelated should be included.
1072. The first line of the commit message should be a short description
108 of the whole commit (ideally <= 50 characters). Then there should
109 be a blank line, followed by a more detailed description of the
110 change.
1123. Follow the stylistic conventions you find in the existing
113 pandoc code. Use spaces, not tabs, and wrap code to 80 columns.
114 Always include type signatures for top-level functions.
115 Consider installing [EditorConfig], this will help you to follow the
116 coding style prevalent in pandoc.
1184. Your code should compile without warnings (`-Wall` clean).
1205. Run the tests to make sure your code does not introduce new bugs.
121 (See below under [Tests](#tests).) All tests should pass.
1236. It is a good idea to add test cases for the bug you are fixing. (See
124 below under [Tests](#tests).) If you are adding a new writer or reader,
125 you must include tests.
1277. If you are adding a new feature, include updates to MANUAL.txt.
1298. All code must be released under the general license governing pandoc
130 (GPL v2).
1329. It is better not to introduce new dependencies. Dependencies on
133 external C libraries should especially be avoided.
13510. We aim for compatibility with ghc versions from 7.8.3 to the
136 latest release. All pull requests and commits are tested
137 automatically on travis-ci.org, using GHC versions in the
138 `Tested-With` stanza of `pandoc.cabal`. We currently relax
139 the "`-Wall` clean" requirement for GHC 7.10.x, because
140 there are so many warnings relating to the addition of type
141 classes to the Prelude.
143Tests
144-----
146Tests can be run as follows:
148 cabal install --only-dependencies --enable-tests
149 cabal configure --enable-tests
150 cabal build
151 cabal test
153or, if you're using [stack],
155 stack setup
156 stack test
158The test program is `tests/test-pandoc.hs`.
160Benchmarks
161----------
163To run benchmarks with cabal:
165 cabal configure --enable-benchmarks
166 cabal build
167 cabal bench
169With stack:
171 stack bench
173Using the REPL
174--------------
176With a recent version of cabal, you can do `cabal repl` and get
177a ghci REPL for working with pandoc. With [stack], use
178`cabal ghci`.
180We recommend using the following `.ghci` file (which can be
181placed in the source directory):
183```
184:set -fobject-code
185:set -XTypeSynonymInstances
186:set -XScopedTypeVariables
187:set -XOverloadedStrings
188```
190The code
191--------
193Pandoc has a publicly accessible git repository on
194github: <http://github.com/jgm/pandoc>. To get a local copy of the source:
196 git clone git://github.com/jgm/pandoc.git
198Note: after cloning the repository (and in the future after pulling from it),
199you should do
201 git submodule update --init
203to pull in changes to the templates (`data/templates/`). You can automate this
204by creating a file `.git/hooks/post-merge` with the contents:
206 #!/bin/sh
207 git submodule update --init
209and making it executable:
211 chmod +x .git/hooks/post-merge
213The source for the main pandoc program is `pandoc.hs`. The source for
214the pandoc library is in `src/`, the source for the tests is in
215`tests/`, and the source for the benchmarks is in `benchmark/`.
217The modules `Text.Pandoc.Definition`, `Text.Pandoc.Builder`, and
218`Text.Pandoc.Generic` are in a separate library `pandoc-types`. The code can
219be found in a <http://github.com/jgm/pandoc-types>.
221To build pandoc, you will need a working installation of the
222[Haskell platform].
224The library is structured as follows:
226 - `Text.Pandoc` is a top-level module that exports what is needed
227 by most users of the library. Any patches that add new readers
228 or writers will need to make changes here, too.
229 - `Text.Pandoc.Definition` (in `pandoc-types`) defines the types
230 used for representing a pandoc document.
231 - `Text.Pandoc.Builder` (in `pandoc-types`) provides functions for
232 building pandoc documents programatically.
233 - `Text.Pandoc.Generics` (in `pandoc-types`) provides functions allowing
234 you to promote functions that operate on parts of pandoc documents
235 to functions that operate on whole pandoc documents, walking the
236 tree automatically.
237 - `Text.Pandoc.Readers.*` are the readers, and `Text.Pandoc.Writers.*`
238 are the writers.
239 - `Text.Pandoc.Biblio` is a utility module for formatting citations
240 using citeproc-hs.
241 - `Text.Pandoc.Data` is used to embed data files when the `embed_data_files`
242 cabal flag is used. It is generated from `src/Text/Pandoc/Data.hsb` using
243 the preprocessor [hsb2hs].
244 - `Text.Pandoc.Highlighting` contains the interface to the
245 highlighting-kate library, which is used for code syntax highlighting.
246 - `Text.Pandoc.ImageSize` is a utility module containing functions for
247 calculating image sizes from the contents of image files.
248 - `Text.Pandoc.MIME` contains functions for associating MIME types
249 with extensions.
250 - `Text.Pandoc.Options` defines reader and writer options.
251 - `Text.Pandoc.PDF` contains functions for producing a PDF from a
252 LaTeX source.
253 - `Text.Pandoc.Parsing` contains parsing functions used in multiple readers.
254 - `Text.Pandoc.Pretty` is a pretty-printing library specialized to
255 the needs of pandoc.
256 - `Text.Pandoc.SelfContained` contains functions for making an HTML
257 file "self-contained," by importing remotely linked images, CSS,
258 and javascript and turning them into `data:` URLs.
259 - `Text.Pandoc.Shared` is a grab-bag of shared utility functions.
260 - `Text.Pandoc.Writers.Shared` contains utilities used in writers only.
261 - `Text.Pandoc.Slides` contains functions for splitting a markdown document
262 into slides, using the conventions described in the MANUAL.
263 - `Text.Pandoc.Templates` defines pandoc's templating system.
264 - `Text.Pandoc.UTF8` contains functions for converting text to and from
265 UTF8 bytestrings (strict and lazy).
266 - `Text.Pandoc.Asciify` contains functions to derive ascii versions of
267 identifiers that use accented characters.
268 - `Text.Pandoc.UUID` contains functions for generating UUIDs.
269 - `Text.Pandoc.XML` contains functions for formatting XML.
271[pandoc-discuss]: http://groups.google.com/group/pandoc-discuss
272[issue tracker]: https://github.com/jgm/pandoc/issues
273[User's Guide]: http://pandoc.org/MANUAL.html
274[FAQs]: http://pandoc.org/faqs.html
275[EditorConfig]: http://editorconfig.org/
276[Haskell platform]: http://www.haskell.org/platform/
277[hsb2hs]: http://hackage.haskell.org/package/hsb2hs
278[enhancement]: https://github.com/jgm/pandoc/labels/enhancement
279[bug]: https://github.com/jgm/pandoc/labels/bug
280[minor]: https://github.com/jgm/pandoc/labels/Minor
281[major]: https://github.com/jgm/pandoc/labels/Major
282[reader]: https://github.com/jgm/pandoc/labels/Reader
283[writer]: https://github.com/jgm/pandoc/labels/Writer
284[docs]: https://github.com/jgm/pandoc/labels/docs
285[inprogress]: https://github.com/jgm/pandoc/labels/inprogress
286[more discussion needed]: https://github.com/jgm/pandoc/labels/More%20discussion%20needed
287[more info needed]: https://github.com/jgm/pandoc/labels/More%20info%20needed
288[stack]: https://github.com/commercialhaskell/stack