| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This was needed, for example, to make some minted options work.
|
|
|
|
Closes #3983.
|
|
Currently it's just treated as a synonym for `\newcommand`.
Handles the second case mentioned in #3983.
|
|
|
|
Previously `\include` wouldn't work if the included file
contained, e.g., a begin without a matching end.
We've changed the Tok type so that it stores a full SourcePos,
rather than just a line and column. So tokens keeep track
of the file they came from. This allows us to use a simpler
method for includes, which doesn't require parsing the included
document as a whole.
Closes #3971.
|
|
This caused quotes to be omitted in `\texttt` contexts.
Closes #3958.
However, a better fix would be to modify the
|
|
|
|
Footnotes can not only be terminated by the start of a new footnote or a
header, but also by two consecutive blank lines.
|
|
|
|
Closes #3947.
|
|
The `\n` export option turns all newlines in the text into hard
linebreaks.
Closes #3950
|
|
Removed `writerSourceURL` from `WriterOptions` (API change).
Added `stSourceURL` to `CommonState`.
It is set automatically by `setInputFiles`.
Text.Pandoc.Class now exports `setInputFiles`, `setOutputFile`.
The type of `getInputFiles` has changed; it now returns `[FilePath]`
instead of `Maybe [FilePath]`.
Functions in Class that formerly took the source URL as a parameter
now have one fewer parameter (`fetchItem`, `downloadOrRead`,
`setMediaResource`, `fillMediaBag`).
Removed `WriterOptions` parameter from `makeSelfContained` in
`SelfContained`.
|
|
|
|
|
|
|
|
The org reader was updated to match current org-mode behavior: the set
of characters which are acceptable to occur as the first or last
character in an org emphasis have been changed and now allows all
non-whitespace chars at the inner border of emphasized text (see
`org-emphasis-regexp-components`).
Fixes: #3933
|
|
* 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 #3916.
|
|
Muse reader: parse {{{ }}} example syntax
|
|
Previously code was not allowed to be followed by comma,
and emphasis was allowed to be followed by letter.
|
|
|
|
|
|
|
|
|
|
We now use the default.latex template for both latex and beamer.
It contains conditionals for the beamer-specific things.
`pandoc -D beamer` will return this template.
|
|
|
|
|
|
Handle ogonek, and fall back correctly with forms like `\"{}`.
|
|
|
|
|
|
|
|
|
|
Previously we had a parse failure if the figure contained
anything besides an image and caption.
|
|
|
|
|
|
Closes #3880.
|
|
Closes #2549.
|
|
|
|
|
|
Test checks that behavior is consistent with Amusewiki
|
|
This behavior is compatible to Amusewiki
|
|
|
|
|
|
Closes #3857.
|
|
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.
|
|
from etoolbox.
Closes #3853.
|
