Parse metadata in defaults files as Markdown?

Parse metadata in defaults files as Markdown?

[Martin Post]

[-- Attachment #1.1: Type: text/plain, Size: 837 bytes --]

In a Pandoc document’s YAML metadata block, or in a Pandoc metadata file, I 
can do this:

variable1: __content__

…and it will be rendered as <strong>content</strong> for HTML.

Doing this in a Pandoc DEFAULTS file:

metadata:
  variable1: __content__

…will render $variable1$ as “__content__”

So – is it possible to have metadata in a defaults file interpreted as 
Markdown?

Thank you.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/a4843b38-f508-4d55-8dd0-35136f401bd1n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 1191 bytes --]

Re: Parse metadata in defaults files as Markdown?

[Albert Krewinkel]

Martin Post <martinpostberlin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> In a Pandoc document’s YAML metadata block, or in a Pandoc metadata file, I can do this:
>
> variable1: __content__
>
> …and it will be rendered as <strong>content</strong> for HTML.
>
> Doing this in a Pandoc DEFAULTS file:
>
> metadata:
>   variable1: __content__
>
> …will render $variable1$ as “__content__”
>
> So – is it possible to have metadata in a defaults file interpreted as Markdown?

I think the only way would be to write a Lua filter that convert strings
to Inlines.

E.g.:


    local strings2md
    strings2md = function (meta)
      for key, value in pairs(meta) do
        if pandoc.utils.type(value) == 'string' then
          -- Convert strings to Markdown
          local blocks = pandoc.read(value).blocks
          meta[key] = pandoc.utils.blocks_to_inlines(blocks)
        elseif pandoc.utils.type(value) == 'List' then
          -- Recurse on lists
          meta[key] = strings2md(value)
        end
      end

      return meta
    end

    Meta = strings2md


-- 
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/87r0mgof6d.fsf%40zeitkraut.de.

Re: Parse metadata in defaults files as Markdown?

[Martin Post]

[-- Attachment #1.1: Type: text/plain, Size: 1897 bytes --]

Thank you, Albert! While this looks feasible & helpful, I have now (after 
many years of using Pandoc…) finally “seen the light”, and I’ll separate 
default files and metadata files, as it should be. 😊

Albert Krewinkel schrieb am Freitag, 29. September 2023 um 23:14:28 UTC+2:

>
> Martin Post <martinpo...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
> > In a Pandoc document’s YAML metadata block, or in a Pandoc metadata 
> file, I can do this:
> >
> > variable1: __content__
> >
> > …and it will be rendered as <strong>content</strong> for HTML.
> >
> > Doing this in a Pandoc DEFAULTS file:
> >
> > metadata:
> > variable1: __content__
> >
> > …will render $variable1$ as “__content__”
> >
> > So – is it possible to have metadata in a defaults file interpreted as 
> Markdown?
>
> I think the only way would be to write a Lua filter that convert strings
> to Inlines.
>
> E.g.:
>
>
> local strings2md
> strings2md = function (meta)
> for key, value in pairs(meta) do
> if pandoc.utils.type(value) == 'string' then
> -- Convert strings to Markdown
> local blocks = pandoc.read(value).blocks
> meta[key] = pandoc.utils.blocks_to_inlines(blocks)
> elseif pandoc.utils.type(value) == 'List' then
> -- Recurse on lists
> meta[key] = strings2md(value)
> end
> end
>
> return meta
> end
>
> Meta = strings2md
>
>
> -- 
> Albert Krewinkel
> GPG: 8eed e3e2 e8c5 6f18 81fe e836 388d c0b2 1f63 1124
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/7f96f150-6981-4163-8f6d-54de50a90c4fn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 2689 bytes --]

Markdown in JSON (was: Parse metadata in defaults files as Markdown?)

[BPJ]

[-- Attachment #1: Type: text/plain, Size: 4241 bytes --]

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




Den fre 29 sep. 2023 23:15Albert Krewinkel <albert+pandoc-9EawChwDxG8hFhg+JK9F0w@public.gmane.org>
skrev:

>
> Martin Post <martinpostberlin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
> > In a Pandoc document’s YAML metadata block, or in a Pandoc metadata
> file, I can do this:
> >
> > variable1: __content__
> >
> > …and it will be rendered as <strong>content</strong> for HTML.
> >
> > Doing this in a Pandoc DEFAULTS file:
> >
> > metadata:
> >   variable1: __content__
> >
> > …will render $variable1$ as “__content__”
> >
> > So – is it possible to have metadata in a defaults file interpreted as
> Markdown?
>
> I think the only way would be to write a Lua filter that convert strings
> to Inlines.
>
> E.g.:
>
>
>     local strings2md
>     strings2md = function (meta)
>       for key, value in pairs(meta) do
>         if pandoc.utils.type(value) == 'string' then
>           -- Convert strings to Markdown
>           local blocks = pandoc.read(value).blocks
>           meta[key] = pandoc.utils.blocks_to_inlines(blocks)
>         elseif pandoc.utils.type(value) == 'List' then
>           -- Recurse on lists
>           meta[key] = strings2md(value)
>         end
>       end
>
>       return meta
>     end
>
>     Meta = strings2md
>
>
> --
> Albert Krewinkel
> GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124
>
> --
> You received this message because you are subscribed to the Google Groups
> "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pandoc-discuss/87r0mgof6d.fsf%40zeitkraut.de
> .
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CADAJKhC6T%3DUHG49Rtd40nYsQFgfMxuiwyjqK3A%2B9CQ0QwjYXzQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 6649 bytes --]

Re: Markdown in JSON (was: Parse metadata in defaults files as Markdown?)

[Albert Krewinkel]

BPJ <melroch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> how and when does `pandoc.json.decode()` parse its argument into AST
> elements?

Decoding to AST elements if possible is the default, but that can be
disabled by passing `false` as the second argument:

     > pandoc.json.decode('{"t":"Str", "c":"Hello"}')
     Str "Hello"
     > type(pandoc.json.decode('{"t":"Str", "c":"Hello"}'))
     userdata

     > pandoc.json.decode('{"t":"Str", "c":"Hello"}', false)
     table: 0xc742c60
     > type(pandoc.json.decode('{"t":"Str", "c":"Hello"}', false))
     table

The "how" is rather simple: the function tries to parse the input as
Inline, Block, Pandoc, Inlines, and Blocks, in that order. If one of
those attempts succeeds, then the respective AST element is returned.
Otherwise it falls back to returning the value as a plain Lua object.


-- 
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124

Re: Markdown in JSON (was: Parse metadata in defaults files as Markdown?)

[BPJ]

[-- Attachment #1: Type: text/plain, Size: 4553 bytes --]

Ah, sorry for the confusion. I didn't understand that it should be JSON in
the style of Pandoc's JSON output, which is quite sensible. I thought it
parsed Markdown, metadata file style. Anyway I came up with a different
solution: I have a metadata field `var-trees` whose value is a string or a
list of strings, each of which is the key of a metadata field whose value
is a mapping of variables. That way I can specify one or more metadata
files each of which contains a variable mapping under its own unique key,
list those keys in the `var-trees` list and have the filter merge all those
trees into a single tree which the filter uses as its
variable-name—variable-value mapping. I have a further frill: if the
variable value is a mapping like this

``````yaml
Seneca:
  first: Lucius Annaeus Seneca
  main: Seneca
``````

the filter will insert the value of `first` the first time it encounters
the variable `` `Seneca`{.var} `` in the document and the value of `main`
on subsequent encounters (obviously with topdown traversal!) In my old Perl
filter I could even have a multi-key variable like

``````yaml
Seneca:
  first: Lucius Annaeus Seneca
  main: Seneca
  profession: philosopher
  job: teacher
  student:
    first: Emperor Nero
    main: Nero
    job: emperor
``````

and then in the document `` `Seneca`{.var} the `Seneca/profession`{.var} ``
but I haven't implemented that yet in the MoonScript/Lua filter. I have
implemented a feature whereby you can have an attribute `c` for "case" on
the "use" of the variable implemented like this in MoonScript (
https://learnxinyminutes.com/docs/moonscript/):

``````moon
-- The values in this table are functions which return a filter table
-- because the capitalized filter needs to use a "fresh" `done`
-- sentinel variable each time!
case_filters = {
  u: -> {
      Str: (el) -> pandoc.Str pandoc.text.upper el.text
    }
  l: ... -- same for lower
  c: ->  -- capitalizes the first char of the first Str in the filtered
value!
    local done
    return {
        Str: (el) ->
          if done
            return nil
          done = true
          return pandoc.Str el.text\gsub utf8.charpattern,
pandoc.text.upper, 1
      }
}

-- then in the main handler:
if case = el.attributes.c
  if case_filter = case_filters[case]
    -- ! == call without arguments (returns filter)
    -- `val` is an Inlines/Blocks list or element
    val = val\walk case_filter!
  else
    error "Unknown case transformation c='#{case}' with variable
'#{el.text}'"
``````

Den mån 2 okt. 2023 21:37Albert Krewinkel <albert+pandoc-9EawChwDxG8hFhg+JK9F0w@public.gmane.org>
skrev:

>
> BPJ <melroch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
> > how and when does `pandoc.json.decode()` parse its argument into AST
> > elements?
>
> Decoding to AST elements if possible is the default, but that can be
> disabled by passing `false` as the second argument:
>
>      > pandoc.json.decode('{"t":"Str", "c":"Hello"}')
>      Str "Hello"
>      > type(pandoc.json.decode('{"t":"Str", "c":"Hello"}'))
>      userdata
>
>      > pandoc.json.decode('{"t":"Str", "c":"Hello"}', false)
>      table: 0xc742c60
>      > type(pandoc.json.decode('{"t":"Str", "c":"Hello"}', false))
>      table
>
> The "how" is rather simple: the function tries to parse the input as
> Inline, Block, Pandoc, Inlines, and Blocks, in that order. If one of
> those attempts succeeds, then the respective AST element is returned.
> Otherwise it falls back to returning the value as a plain Lua object.
>
>
> --
> Albert Krewinkel
> GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124
>
> --
> You received this message because you are subscribed to the Google Groups
> "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pandoc-discuss/87edicolz7.fsf%40zeitkraut.de
> .
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CADAJKhD%3D_D47dbaoFV6x5Y%3DPQUNg-6saPCFQ7ck1KujzFsMVpQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 7115 bytes --]