This reminds me of a thing I ran into with a filter a while ago. The docs say that by default (or at least when the second argument is true) `pandoc.json.decode()` will parse strings as Markdown (or at least that was how I understood it) so I thought that in a tree leaves would be parsed as MD much as in metadata if the second argument is true or missing. Obviously this is not the case. No big deal since this was in a filter ("variable" expansion BTW, what else? :-) I could just use `pandoc.read()` but it did leave me wondering: how and when does `pandoc.json.decode()` parse its argument into AST elements?
FWIW I also came up with another solution: look for the metadata keys `var-data` and `var-trees` as well as for `vars` so I can have this in in-document metadata:
``````yaml
---
vars:
foo: '*foo*'
...
``````
this in a defaults file:
``````yaml
metadata:
var-trees:
- this
- that
``````
and these in three different metadata files:
``````yaml
var-data:
bar: '**bar**'
this:
this: '*this*'
that:
that: '*that*'
``````
I hope you get the idea!
BTW I've come up with a quite effective way to merge values which are iterable with `pairs()` regardless of whether they are actual tables or `Attr.attributes` objects or the like, and just "ignore" non-iterable values, be they nil or whatever:
``````lua
local function merge_maps(...)
local tab = table.pack(...)
local merged = { }
for i = 1, tab.n do
pcall(function()
for k, v in pairs(tab[i]) do
merged[k] = v
end
end)
end
return merged
end
``````
Thanks to the `pcall` the loop will just go on to the next item in `tab` if the current item isn't iterable, without any need for code which tries to inspect the type or tag or whatever of the current item: if `pairs` lives the item is merged, and if `pairs` dies it is just "skipped", so all the "validation" is offloaded to `pairs`.
/bpj