| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
http://txt2tags.org/
There are two points which currently do not match the official
implementation.
1. In the official implementation lists can not be nested like the
following but the reader would interpret this as a bullet list with the
first item being a numbered list.
```
- + This is not a list
```
2. The specification describes how URIs automatically becomes links.
Unfortunately as is often the case, their definitiong of URI is not
clear. I tried three solutions but was unsure about which to adopt.
* Using isURI from Network.URI, this matches far too many strings and is
therefore unsuitable
* Using uri from Text.Pandoc.Shared, this doesn't match all strings that
the reference implementation matches
* Try to simulate the regex which is used in the native code
I went with the third approach but it is not perfect, for example
trailing punctuation is captured in Urls.
|
|
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.
|
|
|
|
|
|
sections."
This reverts commit 2a46042661a088096ac54097db5cd3674438bb63.
|
|
They were previously numbered, starting from the previous numbered
section, which was wrong.
|
|
Or a blockquote or header. Closes #1013.
|
|
This should improve TOC view in iBooks. Closes #1392.
|
|
Closes #1434.
|
|
It now works as in PHP markdown extra. Setting `markdown="1"` on
an outer tag affects all contained tags until it is reversed with
`markdown="0"`. Closes #1378.
Added `stateMarkdownAttribute` to `ParserState`.
|
|
Test case:
<aside markdown="1">
*hi*
</aside>
Previously gave:
<article markdown="1">
<p><em>hi</em> </article></p>
|
|
* 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.
|
|
We need input to be a string so we can print the offending line
on an error.
|
|
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.
|
|
Also removed deprecated readTeXMath.
|
|
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.
|
|
|
|
Removed HTML header scaffolding from data/sample.lua.
|
|
|
|
Thanks @dubiousjim. Close #1431.
|
|
Fix auto identified headers when already auto-id'ed
|
|
If header anchors (bookmarks in a header paragraph) already have an
auto-id, which will happen if they're generated by pandoc, we don't want
to rename it twice, and thus end up with an unnecessary number at the
end. So we add a state value to check if we're in a header. If we are,
we don't rename the bookmark -- wait until we rename it in our header
handling.
|
|
We don't need `updateDState` -- the built-in `modify` works just
fine. And we redefine `withDState` to use modify.
|
|
|
|
This allows them to be styled using `\urlstyle{tt}`.
Thanks to Ulrike Fischer for the solution.
|
|
This allows easier diff-ability. Closes #1424.
|
|
Close #1427.
|
|
Closes #1421.
|
|
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)
|
|
|
|
|
|
(#1398)
|
|
|
|
* Use uppercase HTML tags for block-level content, lowercase for
inline.
* Newline before closing HTML tag.
|
|
* mediawiki > dokuwiki
* ignore raw content other than html or dokuwiki.
(#1398)
|
|
|
|
|
|
As far as I can tell, it does about the same thing.
|
|
|
|
|
|
Use removeFormatting from Shared instead of the custom unfancy
function.
|
|
API change (addition of exported function).
|
|
This properly handles tags that should be self-closing.
Previously `<hr/>` would appear in EPUB output as `<hr></hr>`.
Closes #1420.
|
|
Thanks to @dubiousjim. Closes #1419.
|
|
This originated with @dubiousjim's observation in #1419
that there was a typo in the definition of enDash.
It returned an em dash character instead of an en dash.
I thought about why this had not been noticed before, and
realized that en dashes were just being parsed as regular
symbols.
That made me realize that, now that we no longer have
dedicate EnDash, EmDash, and Ellipses inline elements, as
we used to in pandoc, we no longer need to parse the
unicode characters specially. This allowed a considerable
simplification of the code.
Partially resolves #1419.
|
|
|
|
Improvements to Parsing.hs
|
