Custom writers: which elements have default methods in pandoc.scaffolding.Writer?

[bpj]

I expected that all elements would have default methods which just return a bare stringification but obviously that is not the case.

So a couple of related questions:

1. Is there a list somewhere of which elements have default methods?
2. Does the list of element types in the Lua filter documentation coincide with the list of methods which have to be defined in the Writer object?
3. Is it possible to define a generic Writer.Inline or Writer.Block method which will be applied if as yet no specific method has been defined?
4. Is there any way to set things up so that all blocks get separated by layout.blankline without having to return {blankline,element,blankline} from every block method? (I suppose I could set up a "generator" which wraps a function passed as its argument in another function which adds the blanklines but I suppose the wrapper function would have its price!)

[wlupton]

I posted this to pandoc-discuss last year (and haven't looked at it since). Might it help?

All,

With regard to the recent discussion of pandoc 3 custom HTML writers, I've uploaded a sample writer to https://github.com/wlupton/pandoc-html-writer. Sorry for the delay in doing this. See below for the contents of the README.

William

---

Sample pandoc 3 custom writers, both of which use the scaffolding mechanism.

• html-writer.lua is a base writer.
• html-derived-writer.lua is a derived writer and illustrates how to modify the behaviour of the base writer.

There might be a few missing features in the base writer. Also, I believe that there's a problem with the handling of table rowspans and colspans; in addition, please see the XXX comments in the code.

There are also a sample.md file and a makefile.

[bpj]

@wlupton Thanks! I will study it.

Is it OK with you if I leave this open for now because I almost certainly will have follow-up questions?

[tarleb]

We were trying to replicate the behavior of classical custom writers, which would error whenever they encountered an unknown element. But I'm always interested to hear ideas for improvements.

Here's some code that provides default methods for elements:

Writer = pandoc.scaffolding.Writer

Writer.Inline.Space = pandoc.layout.space
Writer.Block.Figure = pandoc.layout.literal '[[Figure]]'

getmetatable(Writer.Inline).__index = function (t, k)
  return rawget(t, k)
    and rawget(t, k)
    or pandoc.utils.stringify
end
getmetatable(Writer.Block).__index = function (t, k)
  return rawget(t, key)
    and rawget(t, key)
    or function (elem)
      if pandoc.utils.type(elem.content) == 'Inlines' then
        return Writer.Inlines(elem.content)
      end
      error("Don't know how to render " .. elem.t)
    end
end

[bpj]

@tarleb Just a thought: won't I have to check the content type of both inlines and blocks because some have the "other" type of content? Header and Note come to mind; I'm not sure there are any others off the top of my head.

[tarleb]

Yes, this isn't a universal default function. Table and CodeBlock elements are problematic, too. I guess just falling back to the markdown writer could be an option that won't fail. But custom redefinitions of for Inline values won't be applied then.

[bpj]

CodeBlock is no problem since in Pod any indented material counts as a code block, so just a non-wrapping Doc with indentation from the CodeBlock text!

For tables I'm thinking of a local filter which inserts some raw "markup" around some inlines and then rendering with the plain writer, as I have done before with filters acting as poor-mans writers.

The big problem is going to be Note. I suppose I can collect them with a filter which appends each Note to a list and replaces it with a link to a "NOTES" heading with current length of the list of notes in square brackets as text, and then add that heading and a list with the notes' bodies at the end of the document body. Unfortunately internal links in Pod can only point at a heading.