Lua functions used to construct AST element values are stored in the Lua
registry for quicker access. Getting a value from the registry is much
faster than getting a global value (partly to idiosyncrasies of hslua);
this change results in a considerable performance boost.
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.
Previously, unquoted string required a space at the end of the
line (and consumed it). Now we either take a space (and don't consume
it), or end of input.
This also necessitated implementing colors and underlining, though
there is currently no way to produce these from markdown. Note that
background colors can't be implemented in PowerPoint, so highlighting
styles that require these will be incomplete.
This picks up the necessary information from meta and carries it over
to the XML output, so Output.hs doesn't need access to the original
pandoc information.
Now list item contents is parsed as blocks,
without resorting to parseFromString.
Only the first line of paragraph has to
be indented now, just like in Emacs Muse
and Text::Amuse.
Definition lists are not refactored yet.
See also: issue #3865.
This is an internal change to the Presentation type. The algebraic
datatype that used to be called `Slide` is now `Layout`, and Slide is
defined as `Slide SlideId Layout (Maybe Notes)`. Though there should
be no user-visible changes in this commit, it offers two benefits
moving forward:
1. Slides now carry their Id with them, instead of being assigned it
in deck order. This makes it easier to set up a link to, say, an
endnotes slide ahead of time.
2. This makes room for Notes slides, when we implement them.
Previously we could get ever-lengthening cell widths
when a table was run repeatedly through `pandoc -f markdown -t
markdown`. This patch stabilizes the relative cell
widths. Closes#4265.
This was a form of hyperlink found in older versions of word. The
changes introduced for this, though, create a framework for parsing
further fields in MS Word (see the spec, ECMA-376-1:2016, §17.16.5,
for more on these fields).
Closes#3389 and #4266.
