Re: Wrapping sections of text with <div></div> in custom filter

["'William Lupton' via pandoc-discuss" <pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>]

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

Am I correct in thinking that when you say "filter" here, you really mean
"writer"?

In filters, you can use the 'traverse' field to force top-down traversal.
See https://pandoc.org/lua-filters.html#traversal-order

In writers, you can choose to call doc:walk(), which will honour
'traverse'. See
https://pandoc.org/custom-writers.html#example-modified-markdown-writer
(and example below)

However, if you use pandoc.scaffolding.Writer (as I think you are?) then I
suspect that you can't control the traversal order (but I'm not sure that
it makes sense to do so, because, for example, surely you always want the
contents of a <div> to have been traversed before you add '<div>' and
'</div>'?).

With the custom writer shown below, and with an input file that consists of
the single line 'Text' (and using my logging module
<https://github.com/pandoc-ext/logging>), you get this with the default
'typewise' traversal:

(#) inline Str "Text"
(#) inlines Inlines[1] {[1] Str "Text"}
(#) block Para {content: Inlines[1] {[1] Str "Text"}}
(#) blocks Blocks[1] {[1] Para {content: Inlines[1] {[1] Str "Text"}}}
(#) meta Meta {}
(#) doc Pandoc {
  blocks: Blocks[1] {
    [1] Para {
      content: Inlines[1] {
        [1] Str "Text"
      }
    }
  }
  meta: Meta {}
}

...and this with 'topdown' traversal:

(#) doc Pandoc {
  blocks: Blocks[1] {
    [1] Para {
      content: Inlines[1] {
        [1] Str "Text"
      }
    }
  }
  meta: Meta {}
}
(#) meta Meta {}
(#) blocks Blocks[1] {[1] Para {content: Inlines[1] {[1] Str "Text"}}}
(#) block Para {content: Inlines[1] {[1] Str "Text"}}
(#) inlines Inlines[1] {[1] Str "Text"}
(#) inline Str "Text"

The writer:

local logging = require 'logging'

local function report(label, elem)
    logging.temp(label, elem)
end

-- 'typewise' (default) or 'topdown'
local traverse = 'topdown'

function Writer (doc, opts)
    local filter = {
        traverse = traverse,
        Inline = function(inline)
            report('inline', inline)
        end,
        Inlines= function(inlines)
            report('inlines', inlines)
        end,
        Block = function(block)
            report('block', block)
        end,
        Blocks = function(blocks)
            report('blocks', blocks)
        end,
        Meta = function(meta)
            report('meta', meta)
        end,
        Pandoc = function(doc)
            report('doc', doc)
        end,
    }
    return pandoc.write(doc:walk(filter), 'html', opts)
end

On Tue, 30 May 2023 at 20:23, H <agents-FcZObrvlYduBUy7/sJONFg@public.gmane.org> wrote:

> On 05/30/2023 02:30 PM, H wrote:
>
> On 05/29/2023 12:31 AM, H wrote:
>
> On May 28, 2023 8:50:56 PM EDT, H <agents-FcZObrvlYduBUy7/sJONFg@public.gmane.org>
> <agents-FcZObrvlYduBUy7/sJONFg@public.gmane.org> wrote:
>>
>> On 05/26/2023 03:43 PM, H wrote:
>>
>> No CSS (I had mentioned that in a previous message), also no
>> modifications to the markdown file so the entire interpretation of layout,
>> adding style information etc. needs to be in my custom PDF writer. This
>> custom writer will - obviously - be specific for this single dedicated use
>> by myself.
>>
>> Any pointers (links, code fragments to look at etc.) as to how I should
>> traverse the tree to be able to output my custom PDF would be greatly
>> appreciated since this will be my first pandoc writer.
>>
>> I am making some progress working on my custom writer for my desired html
>> output layout. I am using the 3.0 syntax where the output function looks
>> like
>>
>> Writer.Pandoc = function(doc)
>>     return Writer.Blocks(doc.blocks)
>> end
>>
>> At the start of my document I also have
>>
>> Writer = pandoc.scaffolding.Writer
>>
>> with customization added for inlines and blocks added.
>>
>> In the Writer.Pandoc function above, is there a way I can see exactly in
>> which order the document is evaluated? I am interested in exploring
>> traverse = 'topdown' vs. traverse = 'typewise' as I think the topdown
>> traversal will be required to add the necessary <div> and </div> in the
>> correct locations to my final document.
>>
>> Again, please bear in mind that I will do /all/ processing in this my
>> custom lua writer.
>>
>> Thanks.
>>
>
> Upon further reading, it looks like the traverse directive might only be
> applicable to filters when the AST is being processed
>
> Is this correct? If so, is there anyway I can view the traversal
> processing sequence in my filter when I am writing and debugging it?
>
> Hoping someone can shed some light on the 'traverse' directive and how I
> can debug my filter using different 'traverse' directives.
>
> Thanks.
>
> Upon further experimentation, it looks like outputting to 'native' format,
> ie the AST tree after running a filter will show me what the modified tree
> looks like.
>
> It would have been nice to have some version of 'verbose' to apply to a
> filter to see in which order elements are processed.
>
>
> --
> 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/05ba5663-1578-d555-8539-d6a2bdff6743%40meddatainc.com
> <https://groups.google.com/d/msgid/pandoc-discuss/05ba5663-1578-d555-8539-d6a2bdff6743%40meddatainc.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAEe_xxhTjZJRuNZFtYMqh1eSNM9yobfgs_YTj2muxs1px0ygjg%40mail.gmail.com.

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