Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
We treat display math like block quotes, and apply FirstParagraph style
to paragraphs that follow them. These can be styled as the user
wishes. (But, when the user is using indentation, this allows for
paragraphs to continue after display math without indentation.)
|
|
In Writers.Shared, we strip leading and trailing spaces for display
math. Since SoftBreak's are treated as spaces, we should strip those
too.
|
|
|
|
Org reader: support figure labels
|
|
|
|
Figure labels given as `#+LABEL: thelabel` are used as the ID of the
respective image. This allows e.g. the LaTeX to add proper `\label`
markup.
This fixes half of #2496 and #2999.
|
|
Spaces are not allowed in the image URL in textile.
Closes #2998.
|
|
Closes #2920.
|
|
The link
`<foo>`_
should have `foo` as both its link text and its URL.
See RST spec at
<http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#embedded-uris-and-aliases>
"The reference text may also be omitted, in which case the URI will be
duplicated for use as the reference text. This is useful for relative
URIs where the address or file name is also the desired reference text:
See `<a_named_relative_link>`_ or `<an_anonymous_relative_link>`__
for details."
Closes Debian #828167 -- reported by Christian Heller.
|
|
Closes #1177. This is a convenient option for people using
websites whose Markdown flavors don't provide for math.
|
|
|
|
Previously they were processed, very unintuitively, in R->L
order, so that `markdown-tex_math_dollars+tex_math_dollars`
had `tex_math_dollars` disabled.
Closes #2995.
|
|
See #2708. Needs testing to see if this resolves the issue.
Thanks to @nkalvi.
|
|
Attributes can't be followed by a space.
So,
_(class)emph_
but
_(noclass) emph_
Closes #2984.
|
|
Markdown line breaks involve a newline, and simple and pipe
tables can't contain one.
Closes #2993.
|
|
|
|
We test for comments, using all track-changes options. Note that we
should only output comments if `--track-changes=all`. We also test for
emitting warnings if there is complicated formatting.
|
|
We test to see if we emit any warnings.
|
|
We can't guarantee we'll convert every comment correctly, though we'll
do the best we can. This warns if the comment includes something other
than Para or Plain.
|
|
Previously we had only allowed for warnings in the parser. Now we allow
for them in the `Docx.hs` as well. The warnings are simply concatenated.
|
|
This adds simple track-changes comment parsing to the docx reader. It is
turned on with `--track-changes=all`. All comments are converted to
inlines, which can list some information. In the future a warning will
be added for comments with formatting that seems like it will be
excessively denatured.
Note that comments can extend across blocks. For that reason there are
two spans: `comment-start` and `comment-end`. `comment-start` will
contain the comment. `comment-end` will always be empty. The two will be
associated by a numeric id.
|
|
|
|
This is a lossy function for converting `[Block] -> [Inline]`. Its main
use, at the moment, is for docx comments, which can contain arbitrary
blocks (except for footnotes), but which will be converted to spans.
This is, at the moment, pretty useless for everything but the basic
`Para` and `Plain` comments. It can be improved, but the docx reader
should probably emit a warning if the comment contains more than this.
|
|
Org reader: remove partial functions
|
|
Previously we just passed all raw TeX through when MathJax
was used for HTML math. This passed through too much.
With this patch, only raw LaTeX environments that MathJax
can handle get passed through.
This patch also causes raw LaTeX environments to be treated
as math, when possible, with MathML and WebTeX output.
Closes #2758.
|
|
|
|
Partial functions like `head` lead to avoidable errors and should be
avoided. They are replaced with total functions.
This fixes #2991.
|
|
Closes #2985.
|
|
- `writerEmailObfuscation` in `defaultWriterOptions` is now
`NoObfuscation`
- the default for the command-line `--email-obfuscation` option is
now `none`.
Closes #2988.
|
|
Documentation updates
|
|
Org reader: raw inlines in arbitrary formats
|
|
Allow tagsoup 0.14
|
|
Building with the new release went fine here, and it works correctly.
|
|
Raw HTML is kept when the output format is Emacs Org mode.
|
|
Org mode allows arbitrary raw inlines ("export snippets" in Emacs
parlance) to be included as `@@format:raw foreign format text@@`.
Support for this features is added to the Org reader.
|
|
Org mode allows arbitrary raw inlines ("export snippets" in Emacs
parlance) to be included as `@@format:raw foreign format text@@`.
Support for this features is added to the Org writer.
|
|
Raw TeX is kept verbatim when the output format is Emacs Org mode.
|
|
MultiMarkdown was only mentioned as a supported Markdown dialect but not
as a possible input or output format. A brief mention is added
everywhere the other supported markdown dialects are mentioned.
This closes #2973.
|
|
This is for better compatibility with babelmark2.
|
|
Docbook writer: Declare xlink namespace in Docbook5 output
|
|
Here's a minimal case:
\documentclass[]{article}
\usepackage{hyperref}
\begin{document}
\section{\%á}
\end{document}
Without this change, this fails on the second invocation of xelatex.
See https://tex.stackexchange.com/questions/313266/and-non-ascii-characters-in-headings
This affects inputs this like
# %á
with pdf output via xelatex.
|
|
|
|
Org reader: "Berkeley style" citation support
|
|
A specification for an official Org-mode citation syntax was drafted by
Richard Lawrence and enhanced with the help of others on the orgmode
mailing list. Basic support for this citation style is added to the
reader.
This closes #1978.
|
|
Semicolons are used as special characters in citations syntax. This
ensures the correct parsing of Pandoc-style citations:
[prefix; @key; suffix]
Previously, parsing would have failed unless there was a space or other
special character as the last <prefix> character.
|
|
|
|
It has no effect, and Hackage wouldn't accept the package.
|
|
We just sign the pkg now.
For some reason we were getting "obsolete resource envelope"
in signing executables. This seems to be documented here
http://stackoverflow.com/questions/25152451/are-mac-app-store-code-sign-resource-envelopes-always-version-1
and seems to be an El Capitan regression. Until a solution
is found, we'll just sign the pkg.
|
|
|