[XEN,for-4.14,2/2] docs-parse-support-md: Cope with buster's pandoc

Commit Message

Ian Jackson June 9, 2020, 11:33 a.m. UTC

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 <[e-mail]>
---
 docs/parse-support-md | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

Patch

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;
     }