| Message ID | 20200609113323.32731-1-ian.jackson@eu.citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [XEN,for-4.14,1/2] docs-parse-support-md: Prepare for copying with pandoc versions | expand |
Ian Jackson writes ("[XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc versions"):
> Different pandoc versions generate, and expect, a different toplevel
> structure for their json output and inpout. Newer pandoc's toplevel
> is a hash. We are going to want to support this. We can tell what
> kind of output we should produce by looking at the input we got (which
> itself came from pandoc). So:
Having just sent this I see the typo `copying' in the title...
I have fixed that in my tree.
Ian.
> -----Original Message----- > From: Ian Jackson <ian.jackson@citrix.com> > Sent: 09 June 2020 12:34 > To: xen-devel@lists.xenproject.org; Andrew Cooper <Andrew.Cooper3@citrix.com>; Paul Durrant > <xadimgnik@gmail.com> > Subject: Re: [XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc versions > > Ian Jackson writes ("[XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc > versions"): > > Different pandoc versions generate, and expect, a different toplevel > > structure for their json output and inpout. Newer pandoc's toplevel > > is a hash. We are going to want to support this. We can tell what > > kind of output we should produce by looking at the input we got (which > > itself came from pandoc). So: > > Having just sent this I see the typo `copying' in the title... > I have fixed that in my tree. > With the typo fixed... Release-acked-by: Paul Durrant <paul@xen.org>
diff --git a/docs/parse-support-md b/docs/parse-support-md index 84f0a96a0f..b9978bfb4d 100755 --- a/docs/parse-support-md +++ b/docs/parse-support-md @@ -232,6 +232,8 @@ sub r_content ($) { } } +our $pandoc_toplevel_constructor; + sub r_toplevel ($) { my ($i) = @_; @@ -241,9 +243,21 @@ sub r_toplevel ($) { $had_unknown = undef; $had_feature = undef; - foreach my $e (@$i) { - next unless ref $e eq 'ARRAY'; - r_content $e; + my $blocks; + if (ref $i eq 'ARRAY') { + $pandoc_toplevel_constructor = sub { + my ($blocks) = @_; + return [ + { unMeta => { } }, + $blocks, + ]; + }; + foreach my $e (@$i) { + next unless ref $e eq 'ARRAY'; + r_content $e; + } + } else { + die; } } @@ -274,10 +288,10 @@ sub pandoc2html_inline ($) { my ($content) = @_; my $json_fh = IO::File::new_tmpfile or die $!; - my $j = to_json([ - { unMeta => { } }, - [{ t => 'Para', c => $content }], - ]) or die $!; + + my $blocks = [{ t => 'Para', c => $content }]; + my $data = $pandoc_toplevel_constructor->($blocks); + my $j = to_json($data) or die $!; print $json_fh $j; flush $json_fh or die $!; seek $json_fh,0,0 or die $!;
Different pandoc versions generate, and expect, a different toplevel structure for their json output and inpout. Newer pandoc's toplevel is a hash. We are going to want to support this. We can tell what kind of output we should produce by looking at the input we got (which itself came from pandoc). So: * Make space for code to read toplevel objects which are not arrays. Currently this code is absent and we just die explicitly (rather than dying because we tried to use a hashref as an array ref). * Move generation of the toplevel json structure out of pandoc2html_inline, and abstract it away through a subref which is set up when we read the input file. This is just prep work. No functional change other than a change to an error message. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> --- docs/parse-support-md | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-)