Age | Commit message (Collapse) | Author | Files | Lines |
|
This character needs special handling in lstinline.
Closes #4939.
|
|
|
|
This reverts commit 5eaff399d5d6dc30b0d453eff42c4101674d75ab.
|
|
`--include-in-header`, `--include-before-body`, `--include-after-body`
|
|
Closes #5251.
|
|
This avoids conflics with things like 'toc'.
|
|
|
|
[API change]
* Depend on ipynb library.
* Add `ipynb` as input and output format.
* Added Text.Pandoc.Readers.Ipynb (supports both nbformat v3 and v4).
* Added Text.Pandoc.Writers.Ipynb (supports nbformat v4).
* Added ipynb readers and writers to T.P.Readers,
T.P.Writers, and T.P.Extensions. Register the
file extension .ipynb for this format.
* Add `PandocIpynbDecodingError` constructor to Text.Pandoc.Error.Error.
* Note: there is no template for ipynb.
|
|
|
|
|
|
We don't want to parse its contents as Markdown or HTML.
Closes #5241.
|
|
Previously the `.0` was interpreted as a file extension,
leading pandoc not to add `.tex` (and thus not to find the
file).
The new behavior matches tex more closely.
|
|
|
|
fixes #2839
|
|
See pandoc/lua-filters#40.
|
|
|
|
Directives of this type without numeric inputs should not have a
`startFrom` attribute; with a blank value, the writers can produce
extra whitespace.
|
|
Closes #5208.
|
|
|
|
* These were added by the RST reader and, for literate Haskell,
by the Markdown and LaTeX readers. There is no point to
this class, and it is not applied consistently by all readers.
See #5047.
* Reverse order of `literate` and `haskell` classes on code blocks
when parsing literate Haskell. Better if `haskell` comes first.
|
|
Closes #5204.
|
|
This matches asciidoctor reference docs.
Closes #4364.
|
|
* Ensure that we don't get > 2 levels of section nesting,
even with slide level > 2.
* If slide level == N but there is no N-level header, make
sure the next header with level > N gets treated as a slide
and put in a section, rather than remaining loose.
Closes #5168.
|
|
See #5190.
|
|
When `minlevel` exceeds the original minimum level observed in the
file to be included, every heading should be shifted rightward.
|
|
Underscore emphasis can't cross table cell boundaries,
but the parser wasn't respecting this, leading to exponential
behavior in documents with table cells containing underscores.
This fixes the original sample; it's possible that there
are other performance issues involving underscores.
Closes #3921.
|
|
Closes #1792
|
|
instead of duplicating code.
|
|
|
|
Closes #5172.
|
|
This is refactored out from the Markdown writer.
IT can be used in other writers to create a generic TOC.
|
|
Closes #3051
|
|
* Add 'landmarks' id attribute to the landmarks nav.
* Replace old default CSS removing numbers from ol.toc li
with new rules that match `nav#toc ol, nav#landmarks ol`.
* We keep the `toc` class on `ol` for backwards compatibility.
|
|
This should be rendered as a space.
Closes #5195.
|
|
* FIX #5183 : zimwiki : remove automatic colon prefix before internal images
![](foo.png) should be converted to {{foo.png}} (relative path)
![](/foo.png] should be converted to {{/foo.png}} (absolute path)
Therefore the ':' prefix is useless and must be removed.
I never used the zimwiki, but i submitted the similar dokuwiki fix.
1. The zimwiki syntax is inspired by dokuwiki
2. The zimwiki documentation does not mention the colon character for images
3. The pandoc zimwiki writer seems to be a copy-paste for the dokuwiki writer
If the PR #5184 is applied, I think this one should be applied too.
|
|
* FIX #5183 : remove automatic ':' prefix before internal image links
`![](foo.png)` should be converted to `{{foo.png}}` (relative path)
`![](/foo.png]` should be converted to `{{/foo.png}}` (absolute path)
Therefore the ':' prefix is useless and must be removed.
It blocks users from making relative image links.
Update tests for DokuWiki Writer : external images
|
|
Fixes a regression introduced by the previous commit.
|
|
Links with descriptions which are pointing to images are no longer read
as inline images, but as proper links.
Fixes: #5191
|
|
|
|
It is updated by some readers, but never actually used.
|
|
Previously we used HsYAML's decodeStrict to recognize
boolean values (treating everything else as a string).
This caused problems relating to hvr/HsYAML#7.
We now just check for the recognized boolean values
`true|True|TRUE|false|False|FALSE`, and avoid using
HsYAML.
Closes #5177.
|
|
closes #5180
|
|
Closes #5187.
|
|
|
|
|
|
Address #5163
|
|
Closes #5149.
|
|
|
|
|
|
See #5162.
|