Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
* T.P.Parsing: Change type of `setLastStrPos` so it takes a
`Maybe SourcePos` rather than a `SourcePos`. [API change]
* T.P.Parsing: Make `parseFromString'` and `gridTableWith` and
`gridTableWith'` polymorphic in the parser state, constraining it with
`HasLastStrPosition`. [API change]
Closes #5708.
|
|
|
|
The haddock module header contains essentially the
same information, so the boilerplate is redundant and
just one more thing to get out of sync.
|
|
Quite a few modules were missing copyright notices.
This commit adds copyright notices everywhere via haddock module
headers. The old license boilerplate comment is redundant with this and has
been removed.
Update copyright years to 2019.
Closes #4592.
|
|
It is updated by some readers, but never actually used.
|
|
|
|
The parameter is Extensions. This allows these functions to
be sensitive to the settings of `Ext_gfm_auto_identifiers` and
`Ext_ascii_identifiers`.
This allows us to use `uniqueIdent` in the CommonMark reader,
replacing some custom code.
It also means that `gfm_auto_identifiers` can now be used
in all formats.
Semantically, `gfm_auto_identifiers` is now a modifier of
`auto_identifiers`; for identifiers to be set, `auto_identifiers`
must be turned on, and then the type of identifier produced
depends on `gfm_auto_identifiers` and `ascii_identifiers` are set.
Closes #5057.
|
|
|
|
|
|
|
|
[API change]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Closes #5010.
Expose trimMath from T.P.Shared.
|
|
|
|
|
|
|
|
|
|
Closes #4637.
|
|
This fixes #4561, a bug parsing emphasized bare links in RST.
|
|
|
|
We previously accepted 'DDC' as 1100. Closes #4480.
|
|
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.
|
|
|
|
|
|
|
|
|
|
The change both improves performance and fixes a
regression whereby normal citations inside inline notes
were not parsed correctly.
Closes jgm/pandoc-citeproc#315.
|
|
|
|
Previously `\( \frac{1}{a} < \frac{1}{b} \)` was not parsed as math
in `markdown` or `html` `+tex_math_single_backslash`.
|
|
This fixes a bug where pandoc would stop parsing a URI with an
empty attribute: for example, `&a=&b=` wolud stop at `a`.
(The uri parser tries to guess which punctuation characters
are part of the URI and which might be punctuation after it.)
Closes #4068.
|
|
|
|
|
|
+ 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.
|
|
Previously pandoc would sometimes combine two line blocks separated by blanks, and ignore trailing blank lines within the line block.
Test is checked to be consisted with http://rst.ninjs.org/
|
|
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.
|
|
This is a utility function to use in list parsing.
|
|
|
|
This reverts commit e22dc98a70d030cc6b4056d14ddd6462c7790f97.
|
|
(Unnecessary type constraints.)
|