| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Closes #2718.
|
|
Previously smart quotes were incorrect in the following:
'$\neg(x \in x)$'.
(because of the following period). This commit fixes the problem,
which was introduced by commit 4229cf2d92faf5774fe1a3a9c89a5de885cf75cd.
|
|
We want to make sure that links have their spaces removed, and are
appropriately smushed together.
This closes #2689
|
|
This gives better results when people write e.g. `\TeX{}` in Markdown.
\TeX{} and \LaTeX{}
now works as expected with `pandoc -f markdown -t latex`.
Closes #2687.
|
|
Put them in a list in the metadata so they are all
preserved, rather than (as before) throwing out all
but one..
|
|
See #2171.
|
|
Closes #2674.
|
|
This avoids performance problems in documents with many identically
named headers.
Closes #2671.
|
|
See fpco/stackage#1096.
|
|
Closes #2645.
In cases where a match was not found for a quote, everything
from the open quote to the end of the paragraph was being dropped.
|
|
Fix function dropping subtrees tagged :noexport:
|
|
Continue scanning for comment subtrees beyond only the first block.
Note to self: when writing an recursive function, don't forget to, you
know, actually recurse.
Shout to @mrvdb for noticing this.
This fixes #2628.
|
|
Closes #2626.
|
|
The reader previously did allow this, following redcloth,
which happily parses
Html blocks can be <div>inlined</div> as well.
as
<p>Html blocks can be <div>inlined</div> as well.</p>
This is invalid HTML, and this kind of thing can lead
to parsing problems (stack overflows) as well. So this
commit undoes this behavior. The above sample now produces;
<p>Html blocks can be</p>
<div>
<p>inlined</p>
</div>
<p>as well.</p>
|
|
Closes #2607.
|
|
Closes #2605.
|
|
For example
\foo
{bar}
{baz}
Closes #2592.
|
|
Previously macro definitions in indented code blocks
were being parsed as macro definitions, not code.
|
|
|
|
and use it in Textile reader
|
|
|
|
Text.Pandoc.Options: Added `Ext_east_asian_line_breaks` constructor to
`Extension` (API change).
This extension is like `ignore_line_breaks`, but smarter -- it
only ignores line breaks between two East Asian wide characters.
This makes it better suited for writing with a mix of East Asian
and non-East Asian scripts.
Closes #2586.
|
|
|
|
Added threefold wrapping option.
* Command line option: deprecated `--no-wrap`, added
`--wrap=[auto|none|preserve]`
* Added WrapOption, exported from Text.Pandoc.Options
* Changed type of writerWrapText in WriterOptions from
Bool to WrapOption.
* Modified Text.Pandoc.Shared functions for SoftBreak.
* Supported SoftBreak in writers.
* Updated tests.
* Updated README.
Closes #1701.
|
|
|
|
Previously pipe table columns got relative widths (based
on the header underscore lines) when the source of one of the rows was
greater in width than the column width. This gave bad results in some
cases where much of the width of the row was due to nonprinting
material (e.g. link URLs). Now pandoc only looks at printable
width (the width of a plain string version of the source), which
should give better results.
Thanks to John Muccigrosso for bringing up the issue.
|
|
closes #2515
|
|
Previously this raised a runtime error.
Closes #2556.
|
|
This fixes redering of unmatched quotes.
Closes #2555.
|
|
Partially addresses #2555.
Note that there's still a problem with the code sample given.
|
|
Change 5527465c introduced a `DummyListItem` type in Docx/Parse.hs. In
retrospect, this seems like it mixes parsing and iterpretation
excessively. What's *really* going on is that we have a list item
without and associate level or numeric info. We can decide what to do
what that in Docx.hs (treat it like a list paragraph), but the parser
shouldn't make that decision.
This commit makes what is going on a bit more explicit. `LevelInfo` is
now a Maybe value in the `ListItem` type. If it's a Nothing, we treat
it as a ListParagraph. If it's a Just, it's a normal list item.
|
|
* Old `link_attributes` -> `mmd_link_attributes`
* Recently added `common_link_attributes` -> `link_attributes`
Note: this change could break some existing workflows.
|
|
mb21-new-image-attributes
* Bumped version to 1.16.
* Added Attr field to Link and Image.
* Added `common_link_attributes` extension.
* Updated readers for link attributes.
* Updated writers for link attributes.
* Updated tests
* Updated stack.yaml to build against unreleased versions of
pandoc-types and texmath.
* Fixed various compiler warnings.
Closes #261.
TODO:
* Relative (percentage) image widths in docx writer.
* ODT/OpenDocument writer (untested, same issue about percentage widths).
* Update pandoc-citeproc.
|
|
This change makes `--no-tex-ligatures` affect the LaTeX reader
as well as the LaTeX and ConTeXt writers. If it is used,
the LaTeX reader will parse characters `` ` ``, `'`, and `-`
literally, rather than parsing ligatures for quotation marks
and dashes. And the LaTeX writer will print unicode quotation
mark and dash characters literally, rather than converting
them to the standard ASCII ligatures.
Note that `--smart` has no affect on the LaTeX reader.
`--smart` is still the default for all input formats when
LaTeX or ConTeXt is the output format, *unless* `--no-tex-ligatures`
is used.
Some examples to illustrate the logic:
```
% echo "'hi'" | pandoc -t latex
`hi'
% echo "'hi'" | pandoc -t latex --no-tex-ligatures
'hi'
% echo "'hi'" | pandoc -t latex --no-tex-ligatures --smart
‘hi’
% echo "'hi'" | pandoc -f latex --no-tex-ligatures
<p>'hi'</p>
% echo "'hi'" | pandoc -f latex
<p>’hi’</p>
```
Closes #2541.
|
|
A residue of a recent change was left around in the form of a
commented-out function. Let's clean that up.
|
|
These come up when people create a list item and then delete the
bullet. It doesn't refer to any real list item, and we used to ignore
it.
We handle it with a DummyListItem type, which, in Docx.hs, is turned
into a normal paragraph with a "ListParagraph" class. If it follow
another list item, it is folded as another paragraph into that item. If
it doesn't, it's just its own (usually indented, and therefore
block-quoted) paragraph.
|
|
We don't have a place yet for styles or sizes on images, but
we can skip the attributes rather than incorrectly taking them
to be part of the filename.
Closes #2515.
|
|
There are separate relationship (link) files for foot and
endnotes. These had previously been grouped together which led to
links not working correctly in notes. This should finally fix that.
|
|
Org reader: Require whitespace around def list markers
|
|
Definition list markers (i.e. double colons `::`) must be surrounded by
whitespace to start a definition item. This rule was not checked
before, resulting in bugs with footnotes and some link types.
Thanks to @conklech for noticing and reporting this issue.
This fixes #2518.
|
|
Org reader: Fix emphasis rules for smart parsing
|
|
This is enabled by default in `markdown_github`.
Added `Ext_emoji` to `Extension` in `Text.Pandoc.Options` (API change).
Closes #2523.
|
|
Smart quotes, ellipses, and dashes should behave like normal quotes,
single dashes, and dots with respect to text markup parsing. The parser
state was not updated properly in all cases, which has been fixed.
Thanks to @conklech for reporting this issue.
This fixes #2513.
|
|
Don't use custom prelude for latest ghc.
This is a better approach to making 'stack ghci' and 'cabal repl'
work. Instead of using NoImplicitPrelude, we only use the custom
prelude for older ghc versions. The custom prelude presents a
uniform API that matches the current base version's prelude.
So, when developing (presumably with latest ghc), we don't
use a custom prelude at all and hence have no trouble with ghci.
The custom prelude no longer exports (<>): we now want to
match the base 4.8 prelude behavior.
|
|
This reverts commit c423dbb5a34c2d1195020e0f0ca3aae883d0749b.
|
|
LaTeX reader: Handle `comment` environment.
|
|
Org reader: fix markup parsing in headers
|
|
This is needed for ghci to work with pandoc, given that we
now use a custom prelude.
Closes #2503.
|
|
Markup as the very first item in a header wasn't recognized. This was
caused by an incorrect parser state: positions at which inline markup
can start need to be marked explicitly by changing the parser state.
This wasn't done for headers. The proper function to update the state
is now called at the beginning of the header parser, fixing this issue.
This fixes #2504.
|
|
The `comment` environment is handled in a similar way to the `verbatim` environment, except that its content is discarded.
|
