Re: latex template syntax vs Lua filters

[BPJ <melroch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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

Also remember that a Lua (or any other programming language) program is
processing instructions with embedded data/variables/text (strings) while a
template is a text with variables and possibly processing instructions
(loops, logic) embedded, i.e. templates are text-centric in a way programs
are not. A program doing the same job as a template will be full of string
concatenations and format strings[^1] which will look disconnected in a way
which template text will not. This was the original use case for templates
before security and separation of functions were big concerns, and it is
still valid.

[^1]: A format string can of course be thought of as a (low-power) template.

Den tis 4 apr. 2023 02:49John MacFarlane <fiddlosopher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> skrev:

> Partly we’ve been motivated by backwards compatibility — adding new
> features but not breaking the original template syntax, which goes back 16
> years or so.
>
> Why not Lua?  In addition to backwards compatibility, you might have
> concerns about safety.  Right now you can be confident that using a
> template won’t launch the missiles, delete a file, or cause an infinite
> loop.
>
> In fact, this can be done right now by adding a generic
> `$insert-author-affiliation$` placeholder in the latex template, and using
> a Lua filter to generate the corresponding data in the AST.
>
>
> That’s a good approach!
>
> Another approach would be to use a custom writer that calls the regular
> pandoc writer but uses its own templating system, written in Lua or
> whatever you like.
>
>
>
> On Apr 3, 2023, at 2:49 PM, bapt a <auguieba-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Hi,
>
> I'm curious to understand the status of / motivations for the
> "mini-language" described in
>
> https://pandoc.org/MANUAL.html#template-syntax
>
> It has become quite complex, with partials, pipes, etc. presumably in
> response to ever-increasing needs to fine-tune the string processing and
> formatting in LaTeX templates. A rather intricate use-case I recently came
> across is to process a list of author-affiliations from Metadata into the
> format requested by a particular journal – for instance:
>
>
> https://github.com/quarto-journals/acs/blob/main/_extensions/acs/title.tex#L1
>
> to follow instructions along those lines in the latex class:
>
> % repeat the \author .. \affiliation etc. as needed
> % \email, \thanks, \homepage, \altaffiliation all apply to the current
> % author. Explanatory text should go in the []'s, actual e-mail
> % address or url should go in the {}'s for \email and \homepage.
> % Please use the appropriate macro foreach each type of information
>
> % \affiliation command applies to all authors since the last
> % \affiliation command. The \affiliation command should follow the
> % other information
> % \affiliation can be followed by \email, \homepage, \thanks as well.
>
> I'm a bit puzzled by the design choice in pandoc templates – would it not
> be (much) easier to process variables in Lua, a fully fledged language with
> built-in support for string manipulation, loops, etc.?
>
> I can imagine a partial "custom writer" of sorts that would be in charge
> of producing, say, the formatted author-affiliation for a given format
> (latex, html, etc.), by manipulating the AST in Lua. This function would be
> called to insert the required content into the TeX file.
>
> In fact, this can be done right now by adding a generic
> `$insert-author-affiliation$` placeholder in the latex template, and using
> a Lua filter to generate the corresponding data in the AST.
>
> Clearly I'm missing something – there must be a good reason for the
> development of the mini-language for templates, beyond the simple scenarios
> (basic for/if constructs). I could see the value of performing simple tasks
> directly in the target latex template, but when it gets as complex as the
> example above I don't quite follow.
>
> Many thanks,
>
> baptiste
>
>
>
>
> --
> 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/d890f12c-84d1-4ab8-a836-0da8fb9c8caan%40googlegroups.com
> <https://groups.google.com/d/msgid/pandoc-discuss/d890f12c-84d1-4ab8-a836-0da8fb9c8caan%40googlegroups.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/BCE2FA1F-296D-4C7E-9495-E4B6E1C5A885%40gmail.com
> <https://groups.google.com/d/msgid/pandoc-discuss/BCE2FA1F-296D-4C7E-9495-E4B6E1C5A885%40gmail.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/CADAJKhBkxMhLAeCTOymphguqG_uHwpUyAnYC4edi%3DSaBkmHS6g%40mail.gmail.com.

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