Org allows users to define their own custom link types. E.g., in a
document with a lot of links to Wikipedia articles, one can define a
custom wikipedia link-type via
#+LINK: wp https://en.wikipedia.org/wiki/
This allows to write [[wp:Org_mode][Org-mode]] instead of the
equivallent [[https://en.wikipedia.org/wiki/Org_mode][Org-mode]].
Internal links in Org are possible by using an anchor-name as the target
of a link:
[[some-anchor][This]] is an internal link.
It links <<some-anchor>> here.
Footnotes can consist of multiple blocks and end only at a header or at
the beginning of another footnote. This fixes the previous behavior,
which restricted notes to a single paragraph.
Support for standard org-blocks is improved. The parser now handles
"HTML", "LATEX", "ASCII", "EXAMPLE", "QUOTE" and "VERSE" blocks in a
sensible fashion.
These are primarily aimed at testing the new treatment of line breaks,
but hopefully other tests can be added more easily now as features
and changes are implemented in the writer.
Adapted from Tests.Writers.HTML.tests.
* Use a <literallayout> for the entire paragraph, not just for the
newline character
* Don't let LineBreaks inside footnotes influence the enclosing
paragraph
This fixes the org-reader's handling of sub- and superscript
expressions. Simple expressions (like `2^+10`), expressions in
parentheses (`a_(n+1)`) and nested sexp (like `a_(nested()parens)`) are
now read correctly.
Support all of the following variants as valid ways to define inline or
display math inlines:
- `\[..\]` (display)
- `$$..$$` (display)
- `\(..\)` (inline)
- `$..$` (inline)
This closes#1223. Again.
Instead of being ignored, attributes are now parsed and
included in Span inlines.
The output will be a bit different from stock textile:
e.g. for `*(foo)hi*`, we'll get `<em><span class="foo">hi</span></em>`
instead of `<em class="foo">hi</em>`. But at least the data is
not lost.
Text such as /*this*/ was not correctly parsed as a strong, emphasised
word. This was due to the end-of-word recognition being to strict as it
did not accept markup chars as part of a word. The fix involves an
additional parser state field, listing the markup chars which might be
parsed as part of a word.
Previously normalisation was handled by the `normalizeSpaces` function. The behavoir of the builder monoid is slightly different and melds together more items such as consecutive strings and spaces adjacent to line breaks. The tests have been changed to reflect this.
All relevant tests passed when the string melding line of the builder monoid was commented out.
rST parser now supports:
- All built-in rST roles
- New role definition
- Role inheritance
Issues/TODO:
- Silently ignores illegal fields on roles
- Silently drops class annotations for roles
- Only supports :format: fields with a single format for :raw: roles,
requires a change to Text.Pandoc.Definition.Format to support multiple
formats.
- Allows direct use of :raw: role, rST only allows indirect (i.e.,
inherited use of :raw:).
A consequence of this change is that the backtick form will be
preferred in general if both are enabled. I think that is good,
as it is much more widespread than the tilde form.
Closes#1084.
This is reported to be necessary to avoid an error from recent
versions of Libre Office when files contain more than one image.
Closes#1069.
Thanks to wmanley for reporting and diagnosing the problem.
Going forward we'll use pandoc-citeproc, as an external filter.
The `--bibliography`, `--csl`, and `--citation-abbreviation` fields
have been removed. Instead one must include `bibliography`, `csl`,
or `csl-abbrevs` fields in the document's YAML metadata. The filter
can then be used as follows:
pandoc --filter pandoc-citeproc
The `Text.Pandoc.Biblio` module has been removed. Henceforth,
`Text.CSL.Pandoc` from pandoc-citations can be used by library users.
The Markdown and LaTeX readers now longer format bibliographies and
citations. That must be done using `processCites` or `processCites'`
from Text.CSL.Pandoc.
All bibliography-related fields have been removed from `ReaderOptions`
and `WriterOptions`: `writerBiblioFiles`, `readerReferences`,
`readerCitationStyle`.
API change.
The code:
~~~{#test}
asdf
~~~
gets compiled to html:
<pre id="test">
asdf
</pre>
So it is possible to link to the identifier `test`
But this doesn't happen on latex
When using the listings package (`--listings`) it is possible to set the
identifier using the `label=test` property:
\begin{lstlisting}[label=id]
hi
\end{lstlisting}
And this is exactly what this patch is doing.
Modified LaTeX Reader/Writer and added tests for this.
* Add ??? as fallback text for non-resolved citations.
* Biblio: Put references (including a header at the end of
the document, if one exists) inside a Div with class "references".
This gives some control over styling of references, and allows
scripts to manipulate them.
* Markdown writer: Print markdown citation codes, and disable
printing of references, if `citations` extension is enabled.
NOTE: It would be good to improve what citeproc-hs does for
a nonexistent key.
When the original document had text containing //, this was previously
included, unchanged, in the dokuwiki output, and this interacted badly
with later, intended, formating text.
Done because I noticed that in the Autolinks section of writer.dokuwiki, the URL in inlined code was getting auto-linked, when it wasn't supposed to.
This also meant that any inline code examples that had text that looked like dokuwiki syntax could break the formatting of later text.
I've found some incorrect behaviours with the dokuwiki output, for which
extra test cases will be needed - that aren't covered by the standard
pandoc test input files.
* Closed#927 (a bug in which `<pre>` in certain contexts was
not recognized as a code block).
* Remove internal HTML tags in code blocks, rather than printing
them verbatim.
* Parse attributes on `<pre>` tag for code blocks.
Now the `title`, `section`, `header`, and `footer` can all be set
individually in metadata. The `description` variable has been
removed.
Quotes have been added so that spaces are allowed in the title.
If you have a title that begins
COMMAND(1) footer here | header here
pandoc will parse it as before into a title, section, header, and
footer. But you can also specify these elements explicitly.
Closes#885.
* Depend on pandoc 1.12.
* Added yaml dependency.
* `Text.Pandoc.XML`: Removed `stripTags`. (API change.)
* `Text.Pandoc.Shared`: Added `metaToJSON`.
This will be used in writers to create a JSON object for use
in the templates from the pandoc metadata.
* Revised readers and writers to use the new Meta type.
* `Text.Pandoc.Options`: Added `Ext_yaml_title_block`.
* Markdown reader: Added support for YAML metadata block.
Note that it must come at the beginning of the document.
* `Text.Pandoc.Parsing.ParserState`: Replace `stateTitle`,
`stateAuthors`, `stateDate` with `stateMeta`.
* RST reader: Improved metadata.
Treat initial field list as metadata when standalone specified.
Previously ALL fields "title", "author", "date" in field lists
were treated as metadata, even if not at the beginning.
Use `subtitle` metadata field for subtitle.
* `Text.Pandoc.Templates`: Export `renderTemplate'` that takes a string
instead of a compiled template..
* OPML template: Use 'for' loop for authors.
* Org template: '#+TITLE:' is inserted before the title.
Previously the writer did this.
rst2html doesn't add `<p>` tags to list items (even when they are
separated by blank lines) unless there are multiple paragraphs in the
list. This commit changes the RST reader to conform more closely to
what docutils does.
Closes#880.
