From 1a58d8dab52f241d52fec1d992d859b9632c4739 Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Tue, 9 Jun 2020 12:26:36 +0100 Subject: [PATCH] docs-parse-support-md: Cope with buster's pandoc Provide the implementation for newer pandoc json. I have done an adhoc test and this now works on both buster and stretch and seems to produce the expected support matrix when run using the example rune (which processes unstable and 4.11). Signed-off-by: Ian Jackson Acked-by: Andrew Cooper Release-acked-by: Paul Durrant --- docs/parse-support-md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/docs/parse-support-md b/docs/parse-support-md index b9978bfb4d..a397637639 100755 --- a/docs/parse-support-md +++ b/docs/parse-support-md @@ -243,6 +243,15 @@ sub r_toplevel ($) { $had_unknown = undef; $had_feature = undef; + # Pandoc's JSON output changed some time between 1.17.2 (stretch) + # and 2.2.1 (buster). I can find no documentation about this + # change or about the compatibility rules. (It seems that + # processing the parse tree *is* supported upstream: they offer + # many libraries to do this inside the pandoc process.) + # Empirically, what has changed is just the top level structure. + # Also pandoc wants the same structure back that it spat out, + # when we ask it to format snippets. + my $blocks; if (ref $i eq 'ARRAY') { $pandoc_toplevel_constructor = sub { @@ -256,6 +265,17 @@ sub r_toplevel ($) { next unless ref $e eq 'ARRAY'; r_content $e; } + } elsif (ref $i eq 'HASH') { + my $api_version = $i->{'pandoc-api-version'}; + $pandoc_toplevel_constructor = sub { + my ($blocks) = @_; + return { + blocks => $blocks, + meta => { }, + 'pandoc-api-version' => $api_version, + }; + }; + r_content $i->{blocks}; } else { die; } -- 2.39.5