Thanks for the solution.
I might not be clear enough in the original post (sometimes I get things too elaborated): probably @jgm is willing to change the behavior in the case that when metadata that is repeatable, collision of command line options and YAML will be catenated instead of ignoring YAML, but this breaks backward compatibility, so he wants to make sure no one is objected to the said new behavior. (because people might rely on the current behavior to override instead of expecting it to be catenated.)
The discussion actually referred to -H option only, but I generalized to “any metadata that is repeatable”.
May be the title is not precise enough. It might be better to say something like: “Discussion Needed—will you hate it if command line option do not override YAML’s metadata when it is repeatable”.
On Saturday, October 29, 2016 at 10:24:33 AM UTC-7, BP Jonsson wrote:
My solution is very simple: I define a separate variable in my templates and use that in metadata, with different keys for different output formats as well as for the beginning/end of header/body, along with a filter which converts codeblocks in said metadata fields into raw blocks of the right format, which is important to prevent breakage. No conflict with `--include-in-header` and its automatically raw semantics arises because they use different template variables.
/bpj
Den 29 okt 2016 05:18 skrev "Kolen Cheung" <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:--This originally started from issue #3138. It concerns how pandoc should handle the case when YAML metadata collides with the command line options.
An Example
The example here concerns
--include-in-header=in command line andheader-includein YAML, but the issue itself is more general, e.g.--include-after-body=, etc.From the manual (emphasis is mine):
-HFILE,--include-in-header=FILE: Include contents of FILE, verbatim, at the end of the header. This can be used, for example, to include special CSS or javascript in HTML documents. This option can be used repeatedly to include multiple files in the header. They will be included in the order specified. Implies
--standalone.Current behavior
Whenever command line option is specified, it will override the YAML metadata defined. Example used in the issue is:
Command line:
pandoc ... -H <file> ..., and in the md file’s yaml:header-includes: - \usepackage{siunitx}
\usepackage{siunitx}will be ignored.“Expected” Behavior
Since the manual said, “This option can be used repeatedly”, it seems natural to assume the same metadata can be defined through both the YAML and command line.
However, it can be imagined people might use command line option to override the YAML option. I agree the command line option should have priority: on option that cannot be repeated, command line option should override. But when an option is repeatable, priority could means command line metadata comes first and YAML comes second, not necessarily means ignoring the later.
Related Discussion: Should Templates Be Recursively Resolved Into?
This is the original purpose of issue #3138: should templates be recursively resolved into? An example is, if I wrote a template snippet, currently
-H/--include-in-header=SNIPPET would not resolve it as a template but include it as is. (There’s a work around mentioned in Pandoc Tricks · jgm/pandoc Wiki.)
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 .
To post to this group, send email to pandoc-...@googlegroups.com .
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/836ca2d4- .6e39-4f7e-b227-69dc06be6f15% 40googlegroups.com
For more options, visit https://groups.google.com/d/optout .