One of the many issues I looked at today mentioned the idea of extending the standard template with a `filter-header-includes` variable, or even a `filter-header-includes.writer` variable. As the OP in that thread observed, it's a bit clunky, but with discipline from filter authors, it could work. The key would be this: filter authors would need to rely on and invariant saying that variable is not set on the command line. @jgm, I'm not sure whether you considered such an extension to the default templates? (Pardon my poor memory, but I got deep into the weeds.)

On Thursday, November 19, 2020 at 2:50:51 PM UTC-5 denis...-FfwAq0itz3ofv37vnLkPlQ@public.gmane.org wrote:

I don't know how that would work with a filter, but wouldn't a custom template be an easier solution? Or what speaks against this?

Best,
Denis

________________________________________
Von: pandoc-...@googlegroups.com <pandoc-...@googlegroups.com> im Auftrag von Norman Ramsey <fells...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Gesendet: Donnerstag, 19. November 2020 20:27:18
An: pandoc-discuss
Betreff: How to add a `\usepackage` in a Lua filter meant to support LaTeX?

I've got a Lua filter that is meant to render certain document elements in a `boxedminipage` environment. To accomplish this feat, I give the element in a suitable `div`, and a Lua filter inserts the LaTeX environment. The document itself remains universal, but the Lua filter is resolutely intended for LaTeX.

The filter adds a raw `\usepackage{boxedminipage2e}` to the `header-includes` of the metadata, but unfortunately when `-V header-includes=...` appears on the command line, it takes precedence and the document metadata is ignored.

I thought of trying to use `-M header-includes=...` instead of `-V header-includes=...`, but that comes with its own problems: using the `-M` option, the argument on the command line is escaped. It is not clear to me if there is a mechanism I can use to put raw LaTeX in that spot.

The issue of the command line overriding metadata has been discussed at some length on the issue tracker (https://github.com/jgm/pandoc/issues/3139) and in pandoc-discuss, where a related issue is laid out in the last post (https://groups.google.com/g/pandoc-discuss/c/N6WhlmSPXbY/m/UYJJBdZwAAAJ).
The discussion thread in pandoc-discuss is now two and a half years old, and it seemed to be in favor of a change. But as of pandoc version 2.11.1.1, no change appears to have been made, and issue #3139 remains open.

Is there a workaround I can add to my Lua filter that will make it work in a self-contained way even in the presence of assignments to the `header-includes` variable on the command line? And is there any thought of #3139 being resolved one way or the other?

--
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-discus...@googlegroups.com<mailto:pandoc-discus...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>.
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/2e27c210-a276-4319-abd7-c81d5db7f7d7n%40googlegroups.com<https://groups.google.com/d/msgid/pandoc-discuss/2e27c210-a276-4319-abd7-c81d5db7f7d7n%40googlegroups.com?utm_medium=email&utm_source=footer>.