Inheritance / fallback for lua writers?

Inheritance / fallback for lua writers?

[Sven Lauer]

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

Hello,

is there a way to "inherit" from another writer when coding a lua writer?

To clarify, my use case: When the output format is latex/pdf, I want to 
render spans with a certain class in a special way.

I could write a custom lua writer, but unless there is an 
inheritance/fallback mechanism, I would have to reproduce all of the 
functionality of the (excellent) standard latex writer, and in the future, 
I would have to update it whenever the standard writer is changed.

So: Is there a way (either on the command line or in the lua writer file) 
to say: "If an element is not defined here, use the element from writer X"? 
(For then, I could simply re-define the rendering function for Span, and 
let all other elements "fall back" to the standard implementation.)

If this is not possible, is there any chance this could be included in the 
future? I would volunteer to help making this happen, but unfortunately my 
Haskell skills are not really existent.

In the most awesome version of this, one would even have an option to 
invoke the "fall back" version of a rendering function (maybe just by 
returning nil?), so that one can say something like:
function Span(s, attr)
   if [has class "foo"] then
      ... do special handling ...
   else 
      ... use implementation from fallback ...
   end
end


This would make it really easy to develop writers that "add on" to existing 
ones, without reinventing the wheel / rewriting the existing writer while 
doing so.

(Right now, I am using a lua filter that transforms the spans in question 
to RawInlines (a la 
https://ulyngs.github.io/blog/posts/2019-02-19-how-to-use-pandoc-filters-for-advanced-customisation-of-your-r-markdown-document/ ) 
- but this seems hacky, since all I want is to specify how to output those 
spans in a particular output format ... which should be done in a writer, 
shouldn't it?

Best,
Sven

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/0520a2cf-0235-4dd0-81d4-5109daedbb4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: Inheritance / fallback for lua writers?

[Albert Krewinkel]

Hi Sven,

Sven Lauer writes:
>
> is there a way to "inherit" from another writer when coding a lua writer?
>
> [...]
>
> If this is not possible, is there any chance this could be included in
> the future?

Pandoc's writers expect full AST elements as inputs, which are not
available to the functions in custom writers: the nested elements have
already been turned into strings. There is thus no sane way to write
such a function. We would need to completely refactor custom writers to
make this possible. Using a filter is the best one can do right now.

> (Right now, I am using a lua filter that transforms the spans in question
> to RawInlines (a la
> https://ulyngs.github.io/blog/posts/2019-02-19-how-to-use-pandoc-filters-for-advanced-customisation-of-your-r-markdown-document/ )
> - but this seems hacky, since all I want is to specify how to output those
> spans in a particular output format ... which should be done in a writer,
> shouldn't it?

Lua filters are a good choice; use-cases like this match the intended
usage. If you'd like, you could add a line like this to the top of your
filter

    if not FORMAT:match 'tex$' then return {} end

This will ensure that the filter won't modify anything unless the target
format is LaTeX.

HTH,

Albert

Re: Inheritance / fallback for lua writers?

[Sven Lauer]

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

Hi Albert,

Pandoc's writers expect full AST elements as inputs, which are not 
> available to the functions in custom writers: the nested elements have 
> already been turned into strings. There is thus no sane way to write 
> such a function. We would need to completely refactor custom writers to 
> make this possible. Using a filter is the best one can do right now. 
>

Thanks for the explanation! I was (mistakenly) assuming that Pandoc's 
writers and lua writers were "on a par", so mixing and matching between 
them seemed at least theoretically doable ...
 

> > (Right now, I am using a lua filter that transforms the spans in 
> question 
> > to RawInlines (a la 
> > 
> https://ulyngs.github.io/blog/posts/2019-02-19-how-to-use-pandoc-filters-for-advanced-customisation-of-your-r-markdown-document/ 
> ) 
> > - but this seems hacky, since all I want is to specify how to output 
> those 
> > spans in a particular output format ... which should be done in a 
> writer, 
> > shouldn't it? 
>
> Lua filters are a good choice; use-cases like this match the intended 
> usage. If you'd like, you could add a line like this to the top of your 
> filter 
>
>     if not FORMAT:match 'tex$' then return {} end 
>
> This will ensure that the filter won't modify anything unless the target 
> format is LaTeX. 
>

Also thanks for the reassurance that I am doing the right thing, and the 
tip (I was doing something like that already).

Sven 

-- 
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 post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/988c2dff-3ee2-4a0f-a14a-4adbc3c6c763%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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