Closed mfhepp closed 2 years ago
@ickc do you know what this might entail? Feel free to assign this issue to me.
From the changelog, this might be relevant:
Use latest pandoc-types, so that toJSONFilter will work with Meta and MetaValue.
In pandoc-types this stands out:
[1.22]
Use untagged JSON encoding for single-constructor types (75, 76, Christian Despres). All of the single constructor types related to Table are now represented in JSON either as arrays (for multi-argument constructors) or as the representation of the inner type (for single argument constructors). This behaviour for newtype-defined and multi-argument non-record types is now consistent across the entire JSON interface, with the exception of Pandoc itself (which is represented as a JSON object with additional metadata). Multi-argument records (of which Citation is the only example) are still represented as objects with the record accessors as keys.
The Meta and Citation types now use derived JSON serialization (newtype and generic, respectively). The format remains the same as before (Christian Despres).
Then, this comment from HadleyW:
This change seems to have had a fairly profound impact on the json AST, but I'm having a hard time figuring exactly what's changed because it's all explained in terms of Haskell types (which I'm not very familiar with). For my particular case, I think it's that the children of Table no longer have
c
children, but their children are instead directly embedded? Does that sound plausible?
And this one:
I think that (maybe with the exception of Meta ?) this assumption was valid until the recent changes to the document model. Now, AFAICT some types with a single constructor have their types erased and some don't. I thought for a moment that the difference was that some where declared with newtype keyword (type erasure) and some with data keyword (no type erasure) which would make sense (if I understand correctly the difference between the two keywords in Haskell) but this second hypothesis doesn't hold either.
To know exactly what changed I think the easiest thing on my end would be to download latest Pandoc, compare Meta and Table JSON representations to what is currently supported, and add changes as needed. Shouldn't be too much of a load.
Panflute 2.1.3 properly spots a version conflict with Pandoc 2.18. As Pandoc 2.18 includes quite some relevant improvements, it would be great to overcome this.
Do you know exactly how/what is the conflict? I tried to run a few cases where the api might have changed but everything seems to be working ok (using latest panflute i.e. 2.1.5)
It would be great to update panflute to Pandoc 2.18.
Pandoc 2.18 uses the latest version of
pandoc-types
, so there may be relevant conflicts.Note that Panflute 2.0.5 did not complain when running with Pandoc 2.18
Panflute 2.1.3 properly spots a version conflict with Pandoc 2.18. As Pandoc 2.18 includes quite some relevant improvements, it would be great to overcome this.
Edit: I removed the issue with a raw element, as this is unrelated as just found out.