Is it possible to overide CLI options with YAML (instead of the other way round)??

Is it possible to overide CLI options with YAML (instead of the other way round)??

[Christopher Grieser]

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

Hi everyone,

I am new to this Forum – if this is the wrong place for this kind of 
question, I apologize; feel free to point me to the right place then.

My question: When there are conflictings between YAML-Metadata and CLI 
options, the standard behavior of Pandoc is a) to extend the information 
(e.g. with --include-in-header) in some cases when it is repeatable, or to 
override the YAML-Metadata with the CLI options (e.g. --csl or 
--bibliography).

Is it somehow possible to control the behavior more precisely? For example: 

   1. in conflicting cases, YAML-Metadata overrides CLI options
   2. in repeatable cases, extend the CLI options with the YAML Metadata.

Option 1 could be useful for the --csl option, when you want to prevent the 
use of a different citation style, when a different user compiles the 
document with a different csl. Option 2 could be useful for --bibliography 
to "add" document-specific citations while you use your main bibliography 
via CLI. (especially the later strikes me as unusual, since with some other 
repeatable options, the YAML-Metadata is extended and not overridden.)

More generally, I am wondering whether there is/could be something like an 
"--yaml-overrides-cli=[true/false]" option to control this behavior?

Best,
Chris



-- 
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/a634a37f-a569-41de-8fad-398fd3eb32e3n%40googlegroups.com.

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

Re: Is it possible to overide CLI options with YAML (instead of the other way round)??

[John MacFarlane]

See
https://github.com/jgm/pandoc/issues/5870
and
https://github.com/jgm/pandoc/issues/4627

Currently defaults files are the way to go for this kind of thing.

Christopher Grieser <grieser.chris-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> Hi everyone,
>
> I am new to this Forum – if this is the wrong place for this kind of 
> question, I apologize; feel free to point me to the right place then.
>
> My question: When there are conflictings between YAML-Metadata and CLI 
> options, the standard behavior of Pandoc is a) to extend the information 
> (e.g. with --include-in-header) in some cases when it is repeatable, or to 
> override the YAML-Metadata with the CLI options (e.g. --csl or 
> --bibliography).
>
> Is it somehow possible to control the behavior more precisely? For example: 
>
>    1. in conflicting cases, YAML-Metadata overrides CLI options
>    2. in repeatable cases, extend the CLI options with the YAML Metadata.
>
> Option 1 could be useful for the --csl option, when you want to prevent the 
> use of a different citation style, when a different user compiles the 
> document with a different csl. Option 2 could be useful for --bibliography 
> to "add" document-specific citations while you use your main bibliography 
> via CLI. (especially the later strikes me as unusual, since with some other 
> repeatable options, the YAML-Metadata is extended and not overridden.)
>
> More generally, I am wondering whether there is/could be something like an 
> "--yaml-overrides-cli=[true/false]" option to control this behavior?
>
> Best,
> Chris
>
>
>
> -- 
> 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/a634a37f-a569-41de-8fad-398fd3eb32e3n%40googlegroups.com.

-- 
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/m24kbufu4t.fsf%40MacBook-Pro-2.hsd1.ca.comcast.net.

Re: Is it possible to overide CLI options with YAML (instead of the other way round)??

[Christopher Grieser]

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

thanks for the quick response. I am not entirely certain whether default 
files fully address the issue. First of all, in the documentation it says
*"Settings from the defaults file may be overridden or extended by 
subsequent options on the command line."*

Am I correct then to assume that Pandoc's priority in case of conflicts is:
1. CLI Options
2. YAML-Metadata from the "default" file
3. YAML Metadata from the input document (or maybe 2 and 3 are switched?)

If this is correct, then I think default files are not a solution to the 
case I described, as I explicitly want to *prevent* the overriding of 
yaml-metadata by the CLI Options. My thinking is that many people 
(including myself actually), have ready-to-go "snippets" of a pandoc 
command with a few options that they use all the time. Now in some cases, 
the Metadata from the YAMl should take precedence over the command line 
options.

*Imagine the following use case: I am a casual user, who wrote one pandoc 
"snippet" with all options I want to use every time I use pandoc. Maybe I 
even created an alias for it. This includes, for example, the use of 
apa.csl as citation style. But for that one document, I actually want to 
use asa.csl, as that one niche journal requires it. I write "csl: 
havard.csl" in the YAML-header. However, when later converting the 
document, I use may pandoc snippet, as I always do. But since it is my 
snippet-to-go, I forget that the snippet includes "--csl apa.csl" and get 
an output with the wrong citation style. If I used an alias for my snippet, 
I will even have a hard time finding out what the problem is.*

I mean, sure, this is very specific case where the general overriding of 
yaml-metadata is not desired. But from what I can tell, a lot of casual 
users of pandoc save some sort of pandoc snippet that they write once, and 
then do not think about any further. Some sort of "yaml-overrides-cli" line 
that could be an option or could be added in the yaml-header could avoid 
some trouble for casual users like avoid?

On Thursday, August 12, 2021 at 7:30:40 PM UTC+2 John MacFarlane wrote:

>
> See
> https://github.com/jgm/pandoc/issues/5870
> and
> https://github.com/jgm/pandoc/issues/4627
>
> Currently defaults files are the way to go for this kind of thing.
>
> Christopher Grieser <griese...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
> > Hi everyone,
> >
> > I am new to this Forum – if this is the wrong place for this kind of 
> > question, I apologize; feel free to point me to the right place then.
> >
> > My question: When there are conflictings between YAML-Metadata and CLI 
> > options, the standard behavior of Pandoc is a) to extend the information 
> > (e.g. with --include-in-header) in some cases when it is repeatable, or 
> to 
> > override the YAML-Metadata with the CLI options (e.g. --csl or 
> > --bibliography).
> >
> > Is it somehow possible to control the behavior more precisely? For 
> example: 
> >
> > 1. in conflicting cases, YAML-Metadata overrides CLI options
> > 2. in repeatable cases, extend the CLI options with the YAML Metadata.
> >
> > Option 1 could be useful for the --csl option, when you want to prevent 
> the 
> > use of a different citation style, when a different user compiles the 
> > document with a different csl. Option 2 could be useful for 
> --bibliography 
> > to "add" document-specific citations while you use your main 
> bibliography 
> > via CLI. (especially the later strikes me as unusual, since with some 
> other 
> > repeatable options, the YAML-Metadata is extended and not overridden.)
> >
> > More generally, I am wondering whether there is/could be something like 
> an 
> > "--yaml-overrides-cli=[true/false]" option to control this behavior?
> >
> > Best,
> > Chris
> >
> >
> >
> > -- 
> > 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...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pandoc-discuss/a634a37f-a569-41de-8fad-398fd3eb32e3n%40googlegroups.com
> .
>

-- 
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/f95177a3-19cd-46f4-8228-cf33898723d9n%40googlegroups.com.

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

Re: Is it possible to overide CLI options with YAML (instead of the other way round)??

[Daniel Staal]

On 8/12/21 2:09 PM, Christopher Grieser wrote:
> If this is correct, then I think default files are not a solution to the 
> case I described, as I explicitly want to /prevent/ the overriding of 
> yaml-metadata by the CLI Options. My thinking is that many people 
> (including myself actually), have ready-to-go "snippets" of a pandoc 
> command with a few options that they use all the time. Now in some 
> cases, the Metadata from the YAMl should take precedence over the 
> command line options.
> 
> /Imagine the following use case: I am a casual user, who wrote one 
> pandoc "snippet" with all options I want to use every time I use pandoc. 
> Maybe I even created an alias for it. This includes, for example, the 
> use of apa.csl as citation style. But for that one document, I actually 
> want to use asa.csl, as that one niche journal requires it. I write 
> "csl: havard.csl" in the YAML-header. However, when later converting the 
> document, I use may pandoc snippet, as I always do. But since it is my 
> snippet-to-go, I forget that the snippet includes "--csl apa.csl" and 
> get an output with the wrong citation style. If I used an alias for my 
> snippet, I will even have a hard time finding out what the problem is./
> /
> /

You're thinking about this wrong, really.  For this case you should have 
all the options for your 'snippet' in the defaults file - then you 
override them with what you want on a specific case on the command line.

This is normal behavior across unix tools: What the user entered is the 
final word, overriding other defaults.  This typically allows the most 
flexibility, and the easiest debugging: You can spend as much time as 
you want configuring your defaults, they can be overriden quickly, and 
you can always see how you're overriding them.

Daniel T. Staal

-- 
---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------

-- 
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/a649c458-6981-c0de-5c69-b6cf15b76693%40usa.net.

Re: Is it possible to overide CLI options with YAML (instead of the other way round)??

[Christopher Grieser]

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

Ah, I see, now I get it. But then I would have follow-up question: When I 
for example set a csl in both, the input document and the default document, 
which csl file gets priority and which gets overriden? (assuming no csl 
option was used in the CLI command.)

I can't really find any definitive statement on this in the documentation. 
It only says that one piece of metadata is used multiple times, the first 
one will be used. But how is that determined with the yaml-metadata located 
in two different files?


On Thursday, August 12, 2021 at 8:15:33 PM UTC+2 DSt...-Jdbf3xiKgS8@public.gmane.org wrote:

> On 8/12/21 2:09 PM, Christopher Grieser wrote:
> > If this is correct, then I think default files are not a solution to the 
> > case I described, as I explicitly want to /prevent/ the overriding of 
> > yaml-metadata by the CLI Options. My thinking is that many people 
> > (including myself actually), have ready-to-go "snippets" of a pandoc 
> > command with a few options that they use all the time. Now in some 
> > cases, the Metadata from the YAMl should take precedence over the 
> > command line options.
> > 
> > /Imagine the following use case: I am a casual user, who wrote one 
> > pandoc "snippet" with all options I want to use every time I use pandoc. 
> > Maybe I even created an alias for it. This includes, for example, the 
> > use of apa.csl as citation style. But for that one document, I actually 
> > want to use asa.csl, as that one niche journal requires it. I write 
> > "csl: havard.csl" in the YAML-header. However, when later converting the 
> > document, I use may pandoc snippet, as I always do. But since it is my 
> > snippet-to-go, I forget that the snippet includes "--csl apa.csl" and 
> > get an output with the wrong citation style. If I used an alias for my 
> > snippet, I will even have a hard time finding out what the problem is./
> > /
> > /
>
> You're thinking about this wrong, really. For this case you should have 
> all the options for your 'snippet' in the defaults file - then you 
> override them with what you want on a specific case on the command line.
>
> This is normal behavior across unix tools: What the user entered is the 
> final word, overriding other defaults. This typically allows the most 
> flexibility, and the easiest debugging: You can spend as much time as 
> you want configuring your defaults, they can be overriden quickly, and 
> you can always see how you're overriding them.
>
> Daniel T. Staal
>
> -- 
> ---------------------------------------------------------------
> This email copyright the author. Unless otherwise noted, you
> are expressly allowed to retransmit, quote, or otherwise use
> the contents for non-commercial purposes. This copyright will
> expire 5 years after the author's death, or in 30 years,
> whichever is longer, unless such a period is in excess of
> local copyright law.
> ---------------------------------------------------------------
>

-- 
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/9378266b-ebeb-40e0-8878-f8e606981ee9n%40googlegroups.com.

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

Re: Is it possible to overide CLI options with YAML (instead of the other way round)??

[Daniel Staal]

On 8/12/21 2:25 PM, Christopher Grieser wrote:
> Ah, I see, now I get it. But then I would have follow-up question: When 
> I for example set a csl in both, the input document and the default 
> document, which csl file gets priority and which gets overriden? 
> (assuming no csl option was used in the CLI command.)
> 
> I can't really find any definitive statement on this in the 
> documentation. It only says that one piece of metadata is used multiple 
> times, the first one will be used. But how is that determined with the 
> yaml-metadata located in two different files?

I'd have to do testing to be sure, but I'd suspect the order is:

defaults->inputdoc->cli

If there's multiple files that could happen at any stage, they'll likely 
be processed in ASCIIBetical order.

Daniel T. Staal

-- 
---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------