| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This fixes a regression in 2.2.3, which cause boolean values to
be parsed as MetaInlines instead of MetaBool.
Note also an undocumented (but desirable) change in 2.2.3:
numbers are now parsed as MetaInlines rather than MetaString.
Closes #4819.
|
|
This fixes a regression in 2.2.3 which caused embedded mappings
(e.g. mappings in sequences) not to work in YAML metadata.
Closes #4817.
|
|
Previously in 2.2.2 you could not do
---
0: bar
...
but only
---
'0': bar
...
With this change, both forms work.
|
|
(Minor)
|
|
Text.Pandoc.Emoji now exports `emojiToInline`, which returns a Span inline containing the emoji character and some attributes with metadata (class `emoji`, attribute `data-emoji` with emoji name). Previously, emojis (as supported in Markdown and CommonMark readers, e.g ":smile:")
were simply translated into the corresponding unicode code point. By wrapping them in Span
nodes, we make it possible to do special handling such as giving them a special font
in HTML output. We also open up the possibility of treating them differently when the
`--ascii` option is selected (though that is not part of this commit).
Closes #4743.
|
|
|
|
yaml wraps a C library; HsYAML is pure Haskell.
Closes #4747. Advances #4535.
|
|
E.g. `` ` ` ``.
|
|
* Markdown writer now includes a blank line at the end
of the row in a single-row multiline table, to prevent it from being
interpreted as a simple table. Closes #4578.
* Markdown reader does a better job computing the relative width of
the last column in a multiline table, so we can round-trip tables
without constantly shrinking the last column.
|
|
See #2944.
|
|
Closes #4560.
|
|
Previously the parser tried to be efficient -- if no end double
quote was found, it would just return the contents. But this
could backfire in a case like:
**this should "be bold**
since the fallback would return the content `"be bold**` and the
closing boldface delimiter would never be encountered.
|
|
This seems to be necessary if we are to use our custom Prelude
with ghci.
Closes #4464.
|
|
|
|
|
|
And a few tweaks related to the Semigroups/Monoid change.
Closes #4448.
|
|
Closes #4281.
Previously we allowed "nonindent spaces" before the
opening and closing `:::`, but this interfered with
list parsing, so now we require the fences to be
flush with the margin of the containing block.
|
|
|
|
if they are separated by a blank line.
See lierdakil/pandoc-crossref#160 for motivation.
|
|
The change both improves performance and fixes a
regression whereby normal citations inside inline notes
were not parsed correctly.
Closes jgm/pandoc-citeproc#315.
|
|
|
|
The rewrite is much more direct, avoiding parseFromString.
And it performs significantly better; unfortunately, parsing
time still increases exponentially.
See #1735.
|
|
This seems to help with the performance problem, #4216.
|
|
Don't pass through macro definitions themselves when `latex_macros`
is set. The macros have already been applied.
If `latex_macros` is enabled, then `rawLaTeXBlock` in
Text.Pandoc.Readers.LaTeX will succeed in parsing a macro definition,
and will update pandoc's internal macro map accordingly, but the
empty string will be returned.
Together with earlier changes, this closes #4179.
|
|
+ Preserve original whitespace between blocks.
+ Recognize `\placeformula` as context.
|
|
A caption starts with a `:` which can't be followed
by punctuation. Otherwise we can falsely interpret
the start of a fenced div, or even a table header line
like `:--:|:--:`, as a caption.
|
|
It would be awkward to indent example list contents to the
first non-space character after the label, since example
list labels are often long.
Thanks to Bernhard Fisseni for the suggestion.
|
|
|
|
Previously we computed the column sizes based on the ratio
between the header lines and the text width (as set by `--columns`).
This meant that tables with very short header lines would be
very narrow. With this change, pipe tables with wrapping cells will
always take up the whole text width. The relative column widths
will still be determined by the ratio of header lines, but they
will be normalized to add up to 1.0.
|
|
Closes #4119.
|
|
Previously if a YAML block under `|-` contained
a blank line, pandoc would not parse it as metadata.
|
|
This brings our handling of them into alignment with
CommonMark's.
Closes #??.
|
|
|
|
Previously the following failed:
::: {.class}
1. one
2. two
:::
and you needed a blank line before the closing `:::`.
|
|
|
|
|
|
|
|
Added test case.
|
|
+ Added Ext_fenced_divs to Extensions (default for pandoc Markdown).
+ Document fenced_divs extension in manual.
+ Implemented fenced code divs in Markdown reader.
+ Added test.
Closes #168.
|
|
Closes #3947.
|
|
* Options: Added readerStripComments to ReaderOptions.
* Added `--strip-comments` command-line option.
* Made `htmlTag` from the HTML reader sensitive to this feature.
This affects Markdown and Textile input.
Closes #2552.
|
|
Eventually we'll add `processEmphasis` and `processBracketed`
to this.
This will allow us to conform to CommonMark rules and
fix #3903 and #1735.
|
|
Closes #3511.
Previously pandoc used the four-space rule: continuation paragraphs,
sublists, and other block level content had to be indented 4
spaces. Now the indentation required is determined by the
first line of the list item: to be included in the list item,
blocks must be indented to the level of the first non-space
content after the list marker. Exception: if are 5 or more spaces
after the list marker, then the content is interpreted as an
indented code block, and continuation paragraphs must be indented
two spaces beyond the end of the list marker. See the CommonMark
spec for more details and examples.
Documents that adhere to the four-space rule should, in most cases,
be parsed the same way by the new rules. Here are some examples
of texts that will be parsed differently:
- a
- b
will be parsed as a list item with a sublist; under the four-space
rule, it would be a list with two items.
- a
code
Here we have an indented code block under the list item, even though it
is only indented six spaces from the margin, because it is four spaces
past the point where a continuation paragraph could begin. With the
four-space rule, this would be a regular paragraph rather than a code
block.
- a
code
Here the code block will start with two spaces, whereas under
the four-space rule, it would start with `code`. With the four-space
rule, indented code under a list item always must be indented eight
spaces from the margin, while the new rules require only that it
be indented four spaces from the beginning of the first non-space
text after the list marker (here, `a`).
This change was motivated by a slew of bug reports from people
who expected lists to work differently (#3125, #2367, #2575, #2210,
#1990, #1137, #744, #172, #137, #128) and by the growing prevalance
of CommonMark (now used by GitHub, for example).
Users who want to use the old rules can select the `four_space_rule`
extension.
* Added `four_space_rule` extension.
* Added `Ext_four_space_rule` to `Extensions`.
* `Parsing` now exports `gobbleAtMostSpaces`, and the type
of `gobbleSpaces` has been changed so that a `ReaderOptions`
parameter is not needed.
|
|
...when there is no intervening blank line.
Closes #3733.
|
|
Previously only `[-@roe]` (with brackets) was recognized as
suppress-author, and `-@roe` was treated the same as `@roe`.
Closes jgm/pandoc-citeproc#237.
|
|
We now disallow reference keys starting with `@` if the
`citations` extension is enabled. Closes #3840.
|
|
It is no longer necessary, since the rawLaTeXBlock parser
will parse macro definitions.
This also avoids the need for a separate latexMacro parser
in the Markdown reader.
|
|
This rewrite is primarily motivated by the need to
get macros working properly. A side benefit is that the
reader is significantly faster (27s -> 19s in one
benchmark, and there is a lot of room for further
optimization).
We now tokenize the input text, then parse the token stream.
Macros modify the token stream, so they should now be effective
in any context, including math. Thus, we no longer need the clunky
macro processing capacities of texmath.
A custom state LaTeXState is used instead of ParserState.
This, plus the tokenization, will require some rewriting
of the exported functions rawLaTeXInline, inlineCommand,
rawLaTeXBlock.
* Added Text.Pandoc.Readers.LaTeX.Types (new exported module).
Exports Macro, Tok, TokType, Line, Column. [API change]
* Text.Pandoc.Parsing: adjusted type of `insertIncludedFile`
so it can be used with token parser.
* Removed old texmath macro stuff from Parsing.
Use Macro from Text.Pandoc.Readers.LaTeX.Types instead.
* Removed texmath macro material from Markdown reader.
* Changed types for Text.Pandoc.Readers.LaTeX's
rawLaTeXInline and rawLaTeXBlock. (Both now return a String,
and they are polymorphic in state.)
* Added orgMacros field to OrgState. [API change]
* Removed readerApplyMacros from ReaderOptions.
Now we just check the `latex_macros` reader extension.
* Allow `\newcommand\foo{blah}` without braces.
Fixes #1390.
Fixes #2118.
Fixes #3236.
Fixes #3779.
Fixes #934.
Fixes #982.
|
|
Closes #3703.
|
|
A figure with an empty caption doesn't make sense.
Closes #2844.
|
