| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Closes #1452. Added test.
|
|
Of course, we can't include structure in the code block, but
this way we at least preserve the text. Closes #1449.
|
|
Closes #1434.
|
|
* This change brings pandoc's definition list syntax into alignment
with that used in PHP markdown extra and multimarkdown (with the
exception that pandoc is more flexible about the definition markers,
allowing tildes as well as colons).
* Lazily wrapped definitions are now allowed; blank space is required
between list items; and the space before definition is used to
determine whether it is a paragraph or a "plain" element.
* For backwards compatibility, a new extension,
`compact_definition_lists`, has been added that restores the behavior
of pandoc 1.12.x, allowing tight definition lists with no blank space
between items, and disallowing lazy wrapping.
|
|
This gives better results for tight lists. Closes #1437.
An alternative solution would be to use Para everywhere, and
never Plain. I am not sufficiently familiar with org to know
which is best. Thoughts, @tarleb?
|
|
Closes #1441.
|
|
Adds support to the org reader for conditionally exporting either the code block,
results block immediately following, both, or neither, depending on the value
of the `:exports` header argument. If no such argument is supplied, the default
org behavior (for most languages) of exporting code is used.
|
|
Fix auto identified headers when already auto-id'ed
|
|
This allows them to be styled using `\urlstyle{tt}`.
Thanks to Ulrike Fischer for the solution.
|
|
Test auto ident header anchors with pandoc-generated pandoc.
|
|
As far as I can see, dokuwiki markup is pretty limited in what
can go in a `>` block quote: just a single line of paragraph
text. (#1398)
|
|
as in the mediawiki writer. The dokuwiki markup isn't able
to handle multiple block-level items within a list item, except
in a few special cases (e.g. code blocks, and these must be started
on the same line as the preceding paragraph). So we fall back to
raw HTML for these.
Perhaps there is a better solution. We can "fake" multiple
paragraphs within list items using hard line breaks (`\\`), but
we must keep everything on one line.
(#1398)
|
|
|
|
|
|
Use removeFormatting from Shared instead of the custom unfancy
function.
|
|
|
|
The standard seems to be captions above tables. (See
http://tex.stackexchange.com/questions/3243/why-should-a-table-caption-be-placed-above-the-table)
|
|
|
|
|
|
|
|
|
|
claremacrae-dokuwiki
|
|
- We no longer include trailing spaces and newlines in the
raw blocks.
- We look for closing tags for elements (but without backtracking).
- Each block-level tag is its own RawBlock; we no longer try to
consolidate them (though `--normalize` will do so).
Closes #1330.
|
|
This reverts commit 23d71b13e7b462229427e2437a8dd9c8f72d72f1.
This is now resulting in a testsuite failure, and I can't see why
it didn't do so before
|
|
|
|
|
|
This doesn't change the testsuite behaviour, but it does mean that
all the testsuite output files are exactly identical to the
output obtained by running the current pandoc.
|
|
This added \cite and \begin latex to the testuite output.
|
|
TODO Also implement nested blockquotes.
|
|
|
|
|
|
For example, this fixes the display of a broken table, and
it also fixes the various HTML horizontal rules.
|
|
* Added normalizeInlines, normalizeBlocks.
* Type signature is now more narrow, `Pandoc -> Pandoc` instead of
`Data a :: a -> a`. Some users may need to change their uses of
`normalize` to the newly exported `normalizeInlines` or
`normalizeBlocks`.
|
|
We want to treat it as a plain paragraph if the hanging amount is
greater to or equal to the left indent---i.e., if the first line has
zero indentation. But we still want it to be a block quote if it starts
to the right of the margin. Someone might format verse with wrapping
lines with a hanging indent, for example.
|
|
The new code was got from inspecting changes in MediaWiki.hs
This slightly changes the output of Div blocks, but I'm not
convinced the original behaviour was really correct anyway.
The code for handling Span does nothing for now, until I can
work out the desired behaviour, and add tests for it.
|
|
|
|
Now doing auto ids for all headers, so tests should reflect that.
|
|
|
|
|
|
This is what seems like the sensible default: read in insertions, and
ignore deletions. In the future, it would be good if options were
available for either taking in deletions or keeping both in some
scriptable format.
|
|
|
|
|
|
Docx rewrite and cleanup (in terms of Reducible typeclass)
|
|
This used to be fixed in the tree-walking. We need to make sure we're doing it
right now.
|
|
Otherwise we get curly quotes in the PDF output.
Closes #1364.
|
|
|
|
|
|
Add torture-test for new normalization functions.
One problem that this test demonstrates is that word has a tendency to
turn off formatting at a space, and then turn it back on after. I'm not
sure yet whether this is something we should fix.
|
|
This is just a wrapper around Pandoc that doesn't normalize with
`toString`. We want to make sure that our own normalization process
works. If, in the future, we are able to hook into the builder's
normalization, this will be removed.
|
|
Previously strikeout highlighted code caused an error.
|
