* Discussion needed—How should pandoc handle when meatada in YAML collide with command line option @ 2016-10-29 3:18 Kolen Cheung [not found] ` <836ca2d4-6e39-4f7e-b227-69dc06be6f15-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 0 siblings, 1 reply; 23+ messages in thread From: Kolen Cheung @ 2016-10-29 3:18 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1.1: Type: text/plain, Size: 2795 bytes --] This originally started from issue #3138 <https://github.com/jgm/pandoc/issues/3138#issuecomment-253699552>. 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 and header-include in YAML, but the issue itself is more general, e.g. --include-after-body=, etc. From the manual (emphasis is mine): -H *FILE*, --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 <https://github.com/jgm/pandoc/issues/3138#issuecomment-253699552>: 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 <https://github.com/jgm/pandoc/wiki/Pandoc-Tricks>.) -- 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/836ca2d4-6e39-4f7e-b227-69dc06be6f15%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 16247 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <836ca2d4-6e39-4f7e-b227-69dc06be6f15-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <836ca2d4-6e39-4f7e-b227-69dc06be6f15-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> @ 2016-10-29 17:24 ` BP Jonsson [not found] ` <CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm+BCbxeTMMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-12-01 11:55 ` Kolen Cheung 1 sibling, 1 reply; 23+ messages in thread From: BP Jonsson @ 2016-10-29 17:24 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 4316 bytes --] 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" <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: > This originally started from issue #3138 > <https://github.com/jgm/pandoc/issues/3138#issuecomment-253699552>. It > concerns how pandoc should handle the case when YAML metadata collides with > the command line options. > <#m_6038354951767356229_>An Example > > The example here concerns --include-in-header= in command line and > header-include in YAML, but the issue itself is more general, e.g. > --include-after-body=, etc. > > From the manual (emphasis is mine): > > -H *FILE*, --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. > > <#m_6038354951767356229_>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. > <#m_6038354951767356229_>“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. > <#m_6038354951767356229_>Related Discussion: Should Templates Be > Recursively Resolved Into? > > This is the original purpose of issue #3138 > <https://github.com/jgm/pandoc/issues/3138#issuecomment-253699552>: > 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 > <https://github.com/jgm/pandoc/wiki/Pandoc-Tricks>.) > > > -- > 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/836ca2d4-6e39-4f7e-b227-69dc06be6f15% > 40googlegroups.com > <https://groups.google.com/d/msgid/pandoc-discuss/836ca2d4-6e39-4f7e-b227-69dc06be6f15%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm%2BBCbxeTMMw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: Type: text/html, Size: 17786 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm+BCbxeTMMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm+BCbxeTMMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-10-31 4:13 ` Kolen Cheung [not found] ` <bd8aea27-38c3-4ace-af2e-6603a64fb977-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 0 siblings, 1 reply; 23+ messages in thread From: Kolen Cheung @ 2016-10-31 4:13 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1.1: Type: text/plain, Size: 5783 bytes --] 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 > <javascript:>>: > >> This originally started from issue #3138 >> <https://github.com/jgm/pandoc/issues/3138#issuecomment-253699552>. It >> concerns how pandoc should handle the case when YAML metadata collides with >> the command line options. >> >> <#CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm+BCbxeTMMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org_m_6038354951767356229_>An >> Example >> >> The example here concerns --include-in-header= in command line and >> header-include in YAML, but the issue itself is more general, e.g. >> --include-after-body=, etc. >> >> From the manual (emphasis is mine): >> >> -H *FILE*, --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. >> >> >> <#CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm+BCbxeTMMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org_m_6038354951767356229_>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. >> >> <#CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm+BCbxeTMMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org_m_6038354951767356229_>“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. >> >> <#CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm+BCbxeTMMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org_m_6038354951767356229_>Related >> Discussion: Should Templates Be Recursively Resolved Into? >> >> This is the original purpose of issue #3138 >> <https://github.com/jgm/pandoc/issues/3138#issuecomment-253699552>: >> 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 >> <https://github.com/jgm/pandoc/wiki/Pandoc-Tricks>.) >> >> >> -- >> 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...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>. >> To post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/pandoc-discuss/836ca2d4-6e39-4f7e-b227-69dc06be6f15%40googlegroups.com >> <https://groups.google.com/d/msgid/pandoc-discuss/836ca2d4-6e39-4f7e-b227-69dc06be6f15%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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/bd8aea27-38c3-4ace-af2e-6603a64fb977%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 49770 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <bd8aea27-38c3-4ace-af2e-6603a64fb977-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <bd8aea27-38c3-4ace-af2e-6603a64fb977-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> @ 2016-10-31 18:14 ` Melroch 0 siblings, 0 replies; 23+ messages in thread From: Melroch @ 2016-10-31 18:14 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 7406 bytes --] I *would* like it but in practice merging data structures is not so straightforward. It can be done in many ways, which may be appropriate or inappropriate depending on what you are going to use each substructure for. See the link below for a nice illustration. https://metacpan.org/pod/Hash::Merge#BUILT-IN-BEHAVIORS (In case you are unfamiliar with Perl `$foo` is a scalar/string value, `@foo` is an array and `%foo` is an associative array aka hash. `$$foo @$foo %$foo` are dereferencing references to a scalar/array/hash -- nested data structures are done with (usually anonymous) references in Perl) Den 31 okt 2016 05:14 skrev "Kolen Cheung" <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: > 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 >>> <https://github.com/jgm/pandoc/issues/3138#issuecomment-253699552>. It >>> concerns how pandoc should handle the case when YAML metadata collides with >>> the command line options. >>> >>> <#m_7733005993067201441_CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm+BCbxeTMMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org_m_6038354951767356229_>An >>> Example >>> >>> The example here concerns --include-in-header= in command line and >>> header-include in YAML, but the issue itself is more general, e.g. >>> --include-after-body=, etc. >>> >>> From the manual (emphasis is mine): >>> >>> -H *FILE*, --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. >>> >>> >>> <#m_7733005993067201441_CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm+BCbxeTMMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org_m_6038354951767356229_>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. >>> >>> <#m_7733005993067201441_CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm+BCbxeTMMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org_m_6038354951767356229_>“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. >>> >>> <#m_7733005993067201441_CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm+BCbxeTMMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org_m_6038354951767356229_>Related >>> Discussion: Should Templates Be Recursively Resolved Into? >>> >>> This is the original purpose of issue #3138 >>> <https://github.com/jgm/pandoc/issues/3138#issuecomment-253699552>: >>> 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 >>> <https://github.com/jgm/pandoc/wiki/Pandoc-Tricks>.) >>> >>> >>> -- >>> 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 post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/pandoc-discuss/836ca2d4-6e39-4f7e-b227-69dc06be6f15%40go >>> oglegroups.com >>> <https://groups.google.com/d/msgid/pandoc-discuss/836ca2d4-6e39-4f7e-b227-69dc06be6f15%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> > > -- > 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/bd8aea27-38c3-4ace-af2e-6603a64fb977% > 40googlegroups.com > <https://groups.google.com/d/msgid/pandoc-discuss/bd8aea27-38c3-4ace-af2e-6603a64fb977%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CADAJKhAUZ2CRHXyeG83YxG4urCQG2yv6kvvOrPuyTfMFmXrDTQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: Type: text/html, Size: 51676 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <836ca2d4-6e39-4f7e-b227-69dc06be6f15-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2016-10-29 17:24 ` BP Jonsson @ 2016-12-01 11:55 ` Kolen Cheung [not found] ` <CADAJKhBWjp7-7-JCrqZXnkaOw8xRtDDv-tCUos29=T1JOTOWkg@mail.gmail.com> 1 sibling, 1 reply; 23+ messages in thread From: Kolen Cheung @ 2016-12-01 11:55 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1.1: Type: text/plain, Size: 1357 bytes --] I was browsing some pandoc filters and see this comment: > pandoc-crossref uses metadata variable `header-includes` to add LaTeX definitions to output. However, Pandoc's command line option `--include-in-header`/`-H` overrides this variable. If you need to use `--include-in-header`, add pandoc-crossref-specific definitions as well. See [LaTeX customization](#latex-customization) for more information. I was thinking to use the `header-includes` in filters to put necessary "template" needed by the filter as well. But without the `-H` override the `header-includes` it won't be stable. It seems that at least there aren't specific reasons/situations when the current behavior is preferred (that `-H` override `header-includes` in YAML). May be we should make the change? -- 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/1902649a-ac7f-4715-a80e-9d9c3659e025%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 2208 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <CADAJKhBWjp7-7-JCrqZXnkaOw8xRtDDv-tCUos29=T1JOTOWkg@mail.gmail.com>]
[parent not found: <CADAJKhA7miFDtn5dOxtFw5VF7TwQMDiXs=8pnrKoOUuVhjoRgQ@mail.gmail.com>]
[parent not found: <CADAJKhA7miFDtn5dOxtFw5VF7TwQMDiXs=8pnrKoOUuVhjoRgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <CADAJKhA7miFDtn5dOxtFw5VF7TwQMDiXs=8pnrKoOUuVhjoRgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-12-02 15:36 ` Melroch [not found] ` <CADAJKhCfDzDaQYSn=iNzM0XXEpisontg=LxrOadmHD6_6aNriw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 23+ messages in thread From: Melroch @ 2016-12-02 15:36 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 2688 bytes --] The simple solution would be for templates to contain something like this ```` $for(filter-header-includes.<output_format>)$ $filter-header-includes.<output_format>$ $endfor$ ```` with filter authors being trusted to make sure that the relevant variable is a MetaBlocks element where each child element is a RawBlock element of the appropriate format. This wouldn't require any code changes at all, just half an hour's work on the templates and some discipline on the part of filter authors. /bpj Den 1 dec 2016 12:55 skrev "Kolen Cheung" <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: I was browsing some pandoc filters and see this comment: > pandoc-crossref uses metadata variable `header-includes` to add LaTeX definitions to output. However, Pandoc's command line option `--include-in-header`/`-H` overrides this variable. If you need to use `--include-in-header`, add pandoc-crossref-specific definitions as well. See [LaTeX customization](#latex-customization) for more information. I was thinking to use the `header-includes` in filters to put necessary "template" needed by the filter as well. But without the `-H` override the `header-includes` it won't be stable. It seems that at least there aren't specific reasons/situations when the current behavior is preferred (that `-H` override `header-includes` in YAML). May be we should make the change? -- 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/1902649a-ac7f-4715-a80e-9d9c3659e025%40googlegroups.com <https://groups.google.com/d/msgid/pandoc-discuss/1902649a-ac7f-4715-a80e-9d9c3659e025%40googlegroups.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- 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/CADAJKhCfDzDaQYSn%3DiNzM0XXEpisontg%3DLxrOadmHD6_6aNriw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: Type: text/html, Size: 4527 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <CADAJKhCfDzDaQYSn=iNzM0XXEpisontg=LxrOadmHD6_6aNriw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <CADAJKhCfDzDaQYSn=iNzM0XXEpisontg=LxrOadmHD6_6aNriw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-12-02 22:42 ` BP Jonsson 2016-12-03 0:28 ` Kolen Cheung 1 sibling, 0 replies; 23+ messages in thread From: BP Jonsson @ 2016-12-02 22:42 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 3743 bytes --] > make sure that the relevant variable is a MetaBlocks element where each child element is a RawBlock element That should of course be a MetaList element with MetaBlocks elements with RawBlock elements. /bpj Den 2 dec 2016 16:37 skrev "Melroch" <melroch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: The simple solution would be for templates to contain something like this ```` $for(filter-header-includes.<output_format>)$ $filter-header-includes.<output_format>$ $endfor$ ```` with filter authors being trusted to make sure that the relevant variable is a MetaBlocks element where each child element is a RawBlock element of the appropriate format. This wouldn't require any code changes at all, just half an hour's work on the templates and some discipline on the part of filter authors. /bpj Den 1 dec 2016 12:55 skrev "Kolen Cheung" <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: I was browsing some pandoc filters and see this comment: > pandoc-crossref uses metadata variable `header-includes` to add LaTeX definitions to output. However, Pandoc's command line option `--include-in-header`/`-H` overrides this variable. If you need to use `--include-in-header`, add pandoc-crossref-specific definitions as well. See [LaTeX customization](#latex-customization) for more information. I was thinking to use the `header-includes` in filters to put necessary "template" needed by the filter as well. But without the `-H` override the `header-includes` it won't be stable. It seems that at least there aren't specific reasons/situations when the current behavior is preferred (that `-H` override `header-includes` in YAML). May be we should make the change? -- 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/ms gid/pandoc-discuss/1902649a-ac7f-4715-a80e-9d9c3659e025%40googlegroups.com <https://groups.google.com/d/msgid/pandoc-discuss/1902649a-ac7f-4715-a80e-9d9c3659e025%40googlegroups.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- 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/CADAJKhCfDzDaQYSn%3DiNzM0XXEpisontg% 3DLxrOadmHD6_6aNriw%40mail.gmail.com <https://groups.google.com/d/msgid/pandoc-discuss/CADAJKhCfDzDaQYSn%3DiNzM0XXEpisontg%3DLxrOadmHD6_6aNriw%40mail.gmail.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- 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/CAFC_yuSvA%2BQ%3DOCBvBx4hCVMZft%3DhhXY-P96OUOGEQ2WB15ODGg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: Type: text/html, Size: 6897 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <CADAJKhCfDzDaQYSn=iNzM0XXEpisontg=LxrOadmHD6_6aNriw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-12-02 22:42 ` BP Jonsson @ 2016-12-03 0:28 ` Kolen Cheung [not found] ` <089593aa-75c3-42fb-9b94-1cf0c01643cd-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 1 sibling, 1 reply; 23+ messages in thread From: Kolen Cheung @ 2016-12-03 0:28 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1.1: Type: text/plain, Size: 3010 bytes --] Ah... the whole point of this discussion is to get rid of custom template, either through a standalone template snippet, or a standalone filter, but not both. On Friday, December 2, 2016 at 7:37:01 AM UTC-8, BP wrote: > > The simple solution would be for templates to contain something like this > > ```` > $for(filter-header-includes.<output_format>)$ > $filter-header-includes.<output_format>$ > > $endfor$ > ```` > > with filter authors being trusted to make sure that the relevant variable > is a MetaBlocks element where each child element is a RawBlock element of > the appropriate format. This wouldn't require any code changes at all, just > half an hour's work on the templates and some discipline on the part of > filter authors. > > /bpj > > > Den 1 dec 2016 12:55 skrev "Kolen Cheung" <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > <javascript:>>: > > I was browsing some pandoc filters and see this comment: > > > pandoc-crossref uses metadata variable `header-includes` to add LaTeX > definitions to output. However, Pandoc's command line option > `--include-in-header`/`-H` overrides this variable. If you need to use > `--include-in-header`, add pandoc-crossref-specific definitions as well. > See [LaTeX customization](#latex-customization) for more information. > > I was thinking to use the `header-includes` in filters to put necessary > "template" needed by the filter as well. But without the `-H` override the > `header-includes` it won't be stable. > > It seems that at least there aren't specific reasons/situations when the > current behavior is preferred (that `-H` override `header-includes` in > YAML). May be we should make the change? > > -- > 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...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>. > To post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pandoc-discuss/1902649a-ac7f-4715-a80e-9d9c3659e025%40googlegroups.com > <https://groups.google.com/d/msgid/pandoc-discuss/1902649a-ac7f-4715-a80e-9d9c3659e025%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > > > -- 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/089593aa-75c3-42fb-9b94-1cf0c01643cd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 5738 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <089593aa-75c3-42fb-9b94-1cf0c01643cd-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <089593aa-75c3-42fb-9b94-1cf0c01643cd-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> @ 2016-12-03 0:38 ` Melroch [not found] ` <CADAJKhCkSC80BR8NDbFKArmRR=80DxxRXQYeEVcBVhiCgxWgYw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 23+ messages in thread From: Melroch @ 2016-12-03 0:38 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 4063 bytes --] I mean the standard templates, but I don't see the point of "getting rid of custom templates". The template and filter features are there because one size does not fit all. /bpj Den 3 dec 2016 01:29 skrev "Kolen Cheung" <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: > Ah... the whole point of this discussion is to get rid of custom template, > either through a standalone template snippet, or a standalone filter, but > not both. > > On Friday, December 2, 2016 at 7:37:01 AM UTC-8, BP wrote: >> >> The simple solution would be for templates to contain something like this >> >> ```` >> $for(filter-header-includes.<output_format>)$ >> $filter-header-includes.<output_format>$ >> >> $endfor$ >> ```` >> >> with filter authors being trusted to make sure that the relevant variable >> is a MetaBlocks element where each child element is a RawBlock element of >> the appropriate format. This wouldn't require any code changes at all, just >> half an hour's work on the templates and some discipline on the part of >> filter authors. >> >> /bpj >> >> >> Den 1 dec 2016 12:55 skrev "Kolen Cheung" <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: >> >> I was browsing some pandoc filters and see this comment: >> >> > pandoc-crossref uses metadata variable `header-includes` to add LaTeX >> definitions to output. However, Pandoc's command line option >> `--include-in-header`/`-H` overrides this variable. If you need to use >> `--include-in-header`, add pandoc-crossref-specific definitions as well. >> See [LaTeX customization](#latex-customization) for more information. >> >> I was thinking to use the `header-includes` in filters to put necessary >> "template" needed by the filter as well. But without the `-H` override the >> `header-includes` it won't be stable. >> >> It seems that at least there aren't specific reasons/situations when the >> current behavior is preferred (that `-H` override `header-includes` in >> YAML). May be we should make the change? >> >> -- >> 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 post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/pandoc-discuss/1902649a-ac7f-4715-a80e-9d9c3659e025%40go >> oglegroups.com >> <https://groups.google.com/d/msgid/pandoc-discuss/1902649a-ac7f-4715-a80e-9d9c3659e025%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- > 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/089593aa-75c3-42fb-9b94-1cf0c01643cd% > 40googlegroups.com > <https://groups.google.com/d/msgid/pandoc-discuss/089593aa-75c3-42fb-9b94-1cf0c01643cd%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CADAJKhCkSC80BR8NDbFKArmRR%3D80DxxRXQYeEVcBVhiCgxWgYw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: Type: text/html, Size: 6255 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <CADAJKhCkSC80BR8NDbFKArmRR=80DxxRXQYeEVcBVhiCgxWgYw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <CADAJKhCkSC80BR8NDbFKArmRR=80DxxRXQYeEVcBVhiCgxWgYw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-12-03 1:21 ` Kolen Cheung [not found] ` <f57e9537-1701-4e48-8d1f-c3d9c43af24f-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 0 siblings, 1 reply; 23+ messages in thread From: Kolen Cheung @ 2016-12-03 1:21 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1.1: Type: text/plain, Size: 7738 bytes --] So you mean sending a pull-request on that modification to the official default template? If @jgm accept it, it at least solves part of the problem: "embedding" the template in the filter so that filter can be standalone. But note that not only `header-include` but also the "before/after" kind of include should be included as well. So these "includes" alone would requires 3 additions per default templates, I'm not really sure if @jgm would accept this. And the actual problem is even bigger, as long as an option can be configured both through YAML and cli, and can be applied repeatedly (i.e. a list), then it falls into this discussion. But this is the controversy, which behavior should be preferred? On one hand, being able to override the config in the documents through cli might be useful in batch processing. But as an author of the document, there should be a reason behind writing things *within* the documents and it is kind of odd it can be overridden *without* changing the markdown source. Even worse, this action is unknown to the author if it build successfully (at least not without manually reading the whole output document). Note that @jgm said that to change pandoc such that the cli options will catenated with the YAML's: > I don't think this would be too difficult a change. > [Template snippet won't be resolved using `includes` such as `-H`, `-B`, `-A` · Issue #3138 · jgm/pandoc](https://github.com/jgm/pandoc/issues/3138#issuecomment-253728066) So the only questions are really 1. would such change break current workflows 2. even if not, which behavior is preferred by the community So far there's no report people are using the current behavior *intentionally* (i.e. their workflow benefit from the current behavior), but on the other hand, recall that the change made in the markdown writer about YAML delimiter: ended with `---` instead of `...`. People relying on the old behavior only start to complain when a new pandoc release implements the new behavior. | -------- Digression ---------- A digression about the last point: this is kind of related to why even Apple nowadays offers beta release (which is so "un-Apple"), somethings just can't be caught by internal testings (or even a discussion group like this here). The end-users might do many "creative" things that the developers aren't aware of, and only knew when it is released (and end-users pissed...). By having some kind of experimental releases (alpha/beta, etc.): 1. breaking change like the said YAML delimiter, or the current one in discussion (cli override YAML or not) can be releases in the experimental releases, which in principle should reach a much wider audiences (at least a significant part of the pandoc community are research students, who usually have the time, and like to, use beta softwares.) 2. include some changes that are just too incomplete to be in the stable pandoc release. Examples are #2818, or hypothetically an AST change which requires a change in all reader/writer-pairs, which is too daunting to do it all at once, but partial release is definitely not stable. 3. At least one of the major drawback is that it just complicated the release process. And I think it should be on a separate repository to not clutter the releases page. | ---------------------------------- On Friday, December 2, 2016 at 4:38:30 PM UTC-8, BP wrote: > > I mean the standard templates, but I don't see the point of "getting rid > of custom templates". The template and filter features are there because > one size does not fit all. > > /bpj > > Den 3 dec 2016 01:29 skrev "Kolen Cheung" <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > <javascript:>>: > >> Ah... the whole point of this discussion is to get rid of custom >> template, either through a standalone template snippet, or a standalone >> filter, but not both. >> >> On Friday, December 2, 2016 at 7:37:01 AM UTC-8, BP wrote: >>> >>> The simple solution would be for templates to contain something like this >>> >>> ```` >>> $for(filter-header-includes.<output_format>)$ >>> $filter-header-includes.<output_format>$ >>> >>> $endfor$ >>> ```` >>> >>> with filter authors being trusted to make sure that the relevant >>> variable is a MetaBlocks element where each child element is a RawBlock >>> element of the appropriate format. This wouldn't require any code changes >>> at all, just half an hour's work on the templates and some discipline on >>> the part of filter authors. >>> >>> /bpj >>> >>> >>> Den 1 dec 2016 12:55 skrev "Kolen Cheung" <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: >>> >>> I was browsing some pandoc filters and see this comment: >>> >>> > pandoc-crossref uses metadata variable `header-includes` to add LaTeX >>> definitions to output. However, Pandoc's command line option >>> `--include-in-header`/`-H` overrides this variable. If you need to use >>> `--include-in-header`, add pandoc-crossref-specific definitions as well. >>> See [LaTeX customization](#latex-customization) for more information. >>> >>> I was thinking to use the `header-includes` in filters to put necessary >>> "template" needed by the filter as well. But without the `-H` override the >>> `header-includes` it won't be stable. >>> >>> It seems that at least there aren't specific reasons/situations when the >>> current behavior is preferred (that `-H` override `header-includes` in >>> YAML). May be we should make the change? >>> >>> -- >>> 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 post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/pandoc-discuss/1902649a-ac7f-4715-a80e-9d9c3659e025%40googlegroups.com >>> <https://groups.google.com/d/msgid/pandoc-discuss/1902649a-ac7f-4715-a80e-9d9c3659e025%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >> 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...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>. >> To post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/pandoc-discuss/089593aa-75c3-42fb-9b94-1cf0c01643cd%40googlegroups.com >> <https://groups.google.com/d/msgid/pandoc-discuss/089593aa-75c3-42fb-9b94-1cf0c01643cd%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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/f57e9537-1701-4e48-8d1f-c3d9c43af24f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 11768 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <f57e9537-1701-4e48-8d1f-c3d9c43af24f-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <f57e9537-1701-4e48-8d1f-c3d9c43af24f-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> @ 2016-12-04 22:32 ` Melroch [not found] ` <CADAJKhDHskio7KYbEo0yXMvLQL+WYYWyh_gO3HNqwCTVRTJB8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-02-01 7:17 ` tolot27 1 sibling, 1 reply; 23+ messages in thread From: Melroch @ 2016-12-04 22:32 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 9779 bytes --] Did I say anything about a pull request? I just pointed out the most sensible way to do it. Actually I think there should be four anchor points. Before the header (or as near the top of the header as practical), at the end of the header, before the user includes, before the body and after the body (but before the user includes in both cases). The number of changes required is a non-issue. The real issue is whether everyone -- filter authors, filter library authors and jgm -- thinks this is the best way to do it. It certainly seems so to me: maximum functionality with minimum added code complexity. At the end of the day it does simply boil down to how both filter authors and document authors should be able to inject code into templates without trampling on each other's feet and without injections showing up in inappropriate formats. There already is a mechanism for injecting data into templates, but we need a separate namespace for doing that with fillers, and subnamespaces for different output formats. /bpj Den 3 dec 2016 02:22 skrev "Kolen Cheung" <christian.kolen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: > So you mean sending a pull-request on that modification to the official > default template? If @jgm accept it, it at least solves part of the > problem: "embedding" the template in the filter so that filter can be > standalone. But note that not only `header-include` but also the > "before/after" kind of include should be included as well. So these > "includes" alone would requires 3 additions per default templates, I'm not > really sure if @jgm would accept this. > > And the actual problem is even bigger, as long as an option can be > configured both through YAML and cli, and can be applied repeatedly (i.e. a > list), then it falls into this discussion. But this is the controversy, > which behavior should be preferred? On one hand, being able to override the > config in the documents through cli might be useful in batch processing. > But as an author of the document, there should be a reason behind writing > things *within* the documents and it is kind of odd it can be overridden > *without* changing the markdown source. Even worse, this action is unknown > to the author if it build successfully (at least not without manually > reading the whole output document). > > Note that @jgm said that to change pandoc such that the cli options will > catenated with the YAML's: > > > I don't think this would be too difficult a change. > > [Template snippet won't be resolved using `includes` such as `-H`, `-B`, > `-A` · Issue #3138 · jgm/pandoc](https://github. > com/jgm/pandoc/issues/3138#issuecomment-253728066) > > So the only questions are really > > 1. would such change break current workflows > 2. even if not, which behavior is preferred by the community > > So far there's no report people are using the current behavior > *intentionally* (i.e. their workflow benefit from the current behavior), > but on the other hand, recall that the change made in the markdown writer > about YAML delimiter: ended with `---` instead of `...`. People relying on > the old behavior only start to complain when a new pandoc release > implements the new behavior. > > > | -------- Digression ---------- > > A digression about the last point: this is kind of related to why even > Apple nowadays offers beta release (which is so "un-Apple"), somethings > just can't be caught by internal testings (or even a discussion group like > this here). The end-users might do many "creative" things that the > developers aren't aware of, and only knew when it is released (and > end-users pissed...). > > By having some kind of experimental releases (alpha/beta, etc.): > > 1. breaking change like the said YAML delimiter, or the current one in > discussion (cli override YAML or not) can be releases in the experimental > releases, which in principle should reach a much wider audiences (at least > a significant part of the pandoc community are research students, who > usually have the time, and like to, use beta softwares.) > > 2. include some changes that are just too incomplete to be in the stable > pandoc release. Examples are #2818, or hypothetically an AST change which > requires a change in all reader/writer-pairs, which is too daunting to do > it all at once, but partial release is definitely not stable. > > 3. At least one of the major drawback is that it just complicated the > release process. And I think it should be on a separate repository to not > clutter the releases page. > > | ---------------------------------- > > On Friday, December 2, 2016 at 4:38:30 PM UTC-8, BP wrote: >> >> I mean the standard templates, but I don't see the point of "getting rid >> of custom templates". The template and filter features are there because >> one size does not fit all. >> >> /bpj >> >> Den 3 dec 2016 01:29 skrev "Kolen Cheung" <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: >> >>> Ah... the whole point of this discussion is to get rid of custom >>> template, either through a standalone template snippet, or a standalone >>> filter, but not both. >>> >>> On Friday, December 2, 2016 at 7:37:01 AM UTC-8, BP wrote: >>>> >>>> The simple solution would be for templates to contain something like >>>> this >>>> >>>> ```` >>>> $for(filter-header-includes.<output_format>)$ >>>> $filter-header-includes.<output_format>$ >>>> >>>> $endfor$ >>>> ```` >>>> >>>> with filter authors being trusted to make sure that the relevant >>>> variable is a MetaBlocks element where each child element is a RawBlock >>>> element of the appropriate format. This wouldn't require any code changes >>>> at all, just half an hour's work on the templates and some discipline on >>>> the part of filter authors. >>>> >>>> /bpj >>>> >>>> >>>> Den 1 dec 2016 12:55 skrev "Kolen Cheung" <christi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: >>>> >>>> I was browsing some pandoc filters and see this comment: >>>> >>>> > pandoc-crossref uses metadata variable `header-includes` to add >>>> LaTeX definitions to output. However, Pandoc's command line option >>>> `--include-in-header`/`-H` overrides this variable. If you need to use >>>> `--include-in-header`, add pandoc-crossref-specific definitions as well. >>>> See [LaTeX customization](#latex-customization) for more information. >>>> >>>> I was thinking to use the `header-includes` in filters to put necessary >>>> "template" needed by the filter as well. But without the `-H` override the >>>> `header-includes` it won't be stable. >>>> >>>> It seems that at least there aren't specific reasons/situations when >>>> the current behavior is preferred (that `-H` override `header-includes` in >>>> YAML). May be we should make the change? >>>> >>>> -- >>>> 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 post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org >>>> To view this discussion on the web visit https://groups.google.com/d/ms >>>> gid/pandoc-discuss/1902649a-ac7f-4715-a80e-9d9c3659e025%40go >>>> oglegroups.com >>>> <https://groups.google.com/d/msgid/pandoc-discuss/1902649a-ac7f-4715-a80e-9d9c3659e025%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> -- >>> 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 post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/pandoc-discuss/089593aa-75c3-42fb-9b94-1cf0c01643cd%40go >>> oglegroups.com >>> <https://groups.google.com/d/msgid/pandoc-discuss/089593aa-75c3-42fb-9b94-1cf0c01643cd%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > 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/f57e9537-1701-4e48-8d1f-c3d9c43af24f% > 40googlegroups.com > <https://groups.google.com/d/msgid/pandoc-discuss/f57e9537-1701-4e48-8d1f-c3d9c43af24f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CADAJKhDHskio7KYbEo0yXMvLQL%2BWYYWyh_gO3HNqwCTVRTJB8g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: Type: text/html, Size: 12787 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <CADAJKhDHskio7KYbEo0yXMvLQL+WYYWyh_gO3HNqwCTVRTJB8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <CADAJKhDHskio7KYbEo0yXMvLQL+WYYWyh_gO3HNqwCTVRTJB8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-12-05 1:13 ` Kolen Cheung [not found] ` <8d8167cf-894c-4dd4-8b1b-1fe8b49b3258-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 0 siblings, 1 reply; 23+ messages in thread From: Kolen Cheung @ 2016-12-05 1:13 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1: Type: text/plain, Size: 51 bytes --] Thanks, I understand more about what you said now. ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <8d8167cf-894c-4dd4-8b1b-1fe8b49b3258-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <8d8167cf-894c-4dd4-8b1b-1fe8b49b3258-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> @ 2017-01-17 17:54 ` mb21 [not found] ` <aed26351-9296-42f2-9711-94f029fb8b0d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 0 siblings, 1 reply; 23+ messages in thread From: mb21 @ 2017-01-17 17:54 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1.1: Type: text/plain, Size: 1164 bytes --] There are a few issues open around how the command line options and the YAML metadata fields interact. https://github.com/jgm/pandoc/issues/3139 https://github.com/jgm/pandoc/issues/3115 https://github.com/jgm/pandoc/issues/3060 Should we consolidate this into one ticket with the docs label, or...? Is there such a ticket already? @jgm How is this going to change in pandoc 2.0? btw, maybe we should have a wiki page describing all the changes under way, or better yet: a "pandoc-2.0" label for all the issues? Also, have you decided when to merge the "typeclass" branch into master? -- 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/aed26351-9296-42f2-9711-94f029fb8b0d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 1874 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <aed26351-9296-42f2-9711-94f029fb8b0d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <aed26351-9296-42f2-9711-94f029fb8b0d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> @ 2017-01-17 18:24 ` Kolen Cheung [not found] ` <7bcf5965-a2fa-41d5-817e-bc27aeba7c7d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2017-01-17 18:47 ` Albert Krewinkel 2017-01-18 11:23 ` John MacFarlane 2 siblings, 1 reply; 23+ messages in thread From: Kolen Cheung @ 2017-01-17 18:24 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1: Type: text/plain, Size: 1776 bytes --] +1 on this, plus #3138. After starting this thread: https://groups.google.com/forum/m/#!topic/pandoc-discuss/LIAfgkZKUiE I realized the "fragmentation" between cli options and YAML options are non-trivial. Because YAML options will be preserved when doing `pandoc -t markdown -s ...`, but cli options are not. And there are problems with the variables under the section "Variables set by pandoc" in the MANUAL. e.g. i don't remember if setting `toc: true` in the yaml works or not, because it is supposed to be set automatically by pandoc when `--toc` is used. I noticed that panzer is invented to solve this problem. Perhaps pandoc 2.0 can have a change on these matters, perhaps taking something from panzer's design. On the other hand, pandoc 2.0, at least as far as the typeclass is concerned, are not meant to break backward compatibility for pandoc as a cli, but only for pandoc as a library (if I understand the 1.19.1 ANN correctly). But may be we should use this chance to break the compatility in cli too. Because this is what is expected from 2.0 anyway. Otherwise these potentially backward incompatibile change will either be never implemented or at least waiting for 3.0. -- 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/7bcf5965-a2fa-41d5-817e-bc27aeba7c7d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <7bcf5965-a2fa-41d5-817e-bc27aeba7c7d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <7bcf5965-a2fa-41d5-817e-bc27aeba7c7d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> @ 2017-01-18 11:03 ` John MacFarlane 2017-01-18 11:25 ` John MacFarlane 1 sibling, 0 replies; 23+ messages in thread From: John MacFarlane @ 2017-01-18 11:03 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw +++ Kolen Cheung [Jan 17 17 10:24 ]: >On the other hand, pandoc 2.0, at least as far as the typeclass is concerned, are not meant to break backward compatibility for pandoc as a cli, but only for pandoc as a library (if I understand the 1.19.1 ANN correctly). But may be we should use this chance to break the compatility in cli too. Because this is what is expected from 2.0 anyway. Otherwise these potentially backward incompatibile change will either be never implemented or at least waiting for 3.0. I am not against breaking cli compatibility and in fact I have already made a few small breaking changes. However, I also don't want to pack so much into pandoc 2.0 that we never finish it. -- 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/20170118110317.GK42333%40Administrateurs-iMac-3.local. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <7bcf5965-a2fa-41d5-817e-bc27aeba7c7d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2017-01-18 11:03 ` John MacFarlane @ 2017-01-18 11:25 ` John MacFarlane [not found] ` <20170118112524.GB44054-BKjuZOBx5Kn2N3qrpRCZGbhGAdq7xJNKhPhL2mjWHbk@public.gmane.org> 1 sibling, 1 reply; 23+ messages in thread From: John MacFarlane @ 2017-01-18 11:25 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw #2139 is also something I'd like to do something about. ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <20170118112524.GB44054-BKjuZOBx5Kn2N3qrpRCZGbhGAdq7xJNKhPhL2mjWHbk@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <20170118112524.GB44054-BKjuZOBx5Kn2N3qrpRCZGbhGAdq7xJNKhPhL2mjWHbk@public.gmane.org> @ 2017-01-23 10:13 ` mb21 [not found] ` <679bf64d-3de1-48e3-b738-0e9059c69a98-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 0 siblings, 1 reply; 23+ messages in thread From: mb21 @ 2017-01-23 10:13 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1.1: Type: text/plain, Size: 798 bytes --] Okay, I've started a wiki page to keep track of the major changes we've been thinking about. https://github.com/jgm/pandoc/wiki/Roadmap The idea is not to include all those in pandoc 2.0 but maybe we manage to do a few... -- 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/679bf64d-3de1-48e3-b738-0e9059c69a98%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 1321 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <679bf64d-3de1-48e3-b738-0e9059c69a98-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <679bf64d-3de1-48e3-b738-0e9059c69a98-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> @ 2017-01-23 10:23 ` John MacFarlane [not found] ` <20170123102338.GL1889-BKjuZOBx5Kn2N3qrpRCZGbhGAdq7xJNKhPhL2mjWHbk@public.gmane.org> 0 siblings, 1 reply; 23+ messages in thread From: John MacFarlane @ 2017-01-23 10:23 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw Great! One change: We already have a LineBlock element! +++ mb21 [Jan 23 17 02:13 ]: > Okay, I've started a wiki page to keep track of the major changes we've > been thinking about. > [1]https://github.com/jgm/pandoc/wiki/Roadmap > The idea is not to include all those in pandoc 2.0 but maybe we manage > to do a few... > > -- > 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 [2]pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To post to this group, send email to > [3]pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To view this discussion on the web visit > [4]https://groups.google.com/d/msgid/pandoc-discuss/679bf64d-3de1-48e3- > b738-0e9059c69a98%40googlegroups.com. > For more options, visit [5]https://groups.google.com/d/optout. > >References > > 1. https://github.com/jgm/pandoc/wiki/Roadmap > 2. mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > 3. mailto:pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > 4. https://groups.google.com/d/msgid/pandoc-discuss/679bf64d-3de1-48e3-b738-0e9059c69a98-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org?utm_medium=email&utm_source=footer > 5. https://groups.google.com/d/optout ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <20170123102338.GL1889-BKjuZOBx5Kn2N3qrpRCZGbhGAdq7xJNKhPhL2mjWHbk@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <20170123102338.GL1889-BKjuZOBx5Kn2N3qrpRCZGbhGAdq7xJNKhPhL2mjWHbk@public.gmane.org> @ 2017-01-23 10:38 ` mb21 [not found] ` <5038f42b-77c9-4e63-a1ed-fbea1342828c-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 0 siblings, 1 reply; 23+ messages in thread From: mb21 @ 2017-01-23 10:38 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1.1: Type: text/plain, Size: 2189 bytes --] Oh, awesome! Corrected in the wiki... On Monday, January 23, 2017 at 11:24:25 AM UTC+1, John MacFarlane wrote: > > Great! One change: We already have a LineBlock element! > > +++ mb21 [Jan 23 17 02:13 ]: > > Okay, I've started a wiki page to keep track of the major changes > we've > > been thinking about. > > [1]https://github.com/jgm/pandoc/wiki/Roadmap > > The idea is not to include all those in pandoc 2.0 but maybe we manage > > to do a few... > > > > -- > > 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 [2]pandoc-discus...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>. > > To post to this group, send email to > > [3]pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>. > > To view this discussion on the web visit > > [4] > https://groups.google.com/d/msgid/pandoc-discuss/679bf64d-3de1-48e3- > > b738-0e9059c69a98%40googlegroups.com. > > For more options, visit [5]https://groups.google.com/d/optout. > > > >References > > > > 1. https://github.com/jgm/pandoc/wiki/Roadmap > > 2. mailto:pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:> > > 3. mailto:pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:> > > 4. > https://groups.google.com/d/msgid/pandoc-discuss/679bf64d-3de1-48e3-b738-0e9059c69a98-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org?utm_medium=email&utm_source=footer > > 5. https://groups.google.com/d/optout > > -- 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/5038f42b-77c9-4e63-a1ed-fbea1342828c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 6547 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <5038f42b-77c9-4e63-a1ed-fbea1342828c-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>]
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <5038f42b-77c9-4e63-a1ed-fbea1342828c-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> @ 2017-01-23 10:50 ` Kolen Cheung 0 siblings, 0 replies; 23+ messages in thread From: Kolen Cheung @ 2017-01-23 10:50 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1: Type: text/plain, Size: 52 bytes --] Something like this could be in the "projects" page ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <aed26351-9296-42f2-9711-94f029fb8b0d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2017-01-17 18:24 ` Kolen Cheung @ 2017-01-17 18:47 ` Albert Krewinkel 2017-01-18 11:23 ` John MacFarlane 2 siblings, 0 replies; 23+ messages in thread From: Albert Krewinkel @ 2017-01-17 18:47 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1: Type: text/plain, Size: 57 bytes --] Also related: https://github.com/jgm/pandoc/issues/1960 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <aed26351-9296-42f2-9711-94f029fb8b0d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2017-01-17 18:24 ` Kolen Cheung 2017-01-17 18:47 ` Albert Krewinkel @ 2017-01-18 11:23 ` John MacFarlane 2 siblings, 0 replies; 23+ messages in thread From: John MacFarlane @ 2017-01-18 11:23 UTC (permalink / raw) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw +++ mb21 [Jan 17 17 09:54 ]: > There are a few issues open around how the command line options and the > YAML metadata fields interact. > [1]https://github.com/jgm/pandoc/issues/3139 > [2]https://github.com/jgm/pandoc/issues/3115 > [3]https://github.com/jgm/pandoc/issues/3060 > Should we consolidate this into one ticket with the docs label, or...? I see these as separate issues, so I'd favor keeping them separate. > @jgm How is this going to change in pandoc 2.0? No changes to this have yet been planned. > btw, maybe we should have a wiki page describing all the changes under > way, or better yet: a "pandoc-2.0" label for all the issues? Ideally this would be good. (And I wouldn't mind a pandoc-2.0 label, so we could keep track of issues to come back to after the typeclass branch has been merged.) A wiki page probably exceeds what I have time for at the moment, but if someone else wants to study the changes made in the typeclass branch and write one, it would be welcome. I've also got a personal list of changes to make in typeclass, but it needs to be organized better before I put it somewhere. Also I'm waiting for feedback from @jkr, who did the lion's share of the work in the changes for pandoc 2.0. > Also, have > you decided when to merge the "typeclass" branch into master? I think it's still premature, since I'm still not sure how long it's going to take to get things to a stable state, and we might want to release further versions in the 1.* series if it takes a long time. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Discussion needed—How should pandoc handle when meatada in YAML collide with command line option [not found] ` <f57e9537-1701-4e48-8d1f-c3d9c43af24f-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2016-12-04 22:32 ` Melroch @ 2018-02-01 7:17 ` tolot27 1 sibling, 0 replies; 23+ messages in thread From: tolot27 @ 2018-02-01 7:17 UTC (permalink / raw) To: pandoc-discuss [-- Attachment #1.1: Type: text/plain, Size: 2019 bytes --] > Note that @jgm said that to change pandoc such that the cli options will > catenated with the YAML's: > > > I don't think this would be too difficult a change. > > [Template snippet won't be resolved using `includes` such as `-H`, `-B`, > `-A` · Issue #3138 · jgm/pandoc]( > https://github.com/jgm/pandoc/issues/3138#issuecomment-253728066) > > So the only questions are really > > 1. would such change break current workflows > 2. even if not, which behavior is preferred by the community > > So far there's no report people are using the current behavior > *intentionally* (i.e. their workflow benefit from the current behavior), > but on the other hand, recall that the change made in the markdown writer > about YAML delimiter: ended with `---` instead of `...`. People relying on > the old behavior only start to complain when a new pandoc release > implements the new behavior. > I run into the overiding problem too and created the issue #4328 <https://github.com/jgm/pandoc/issues/4328>. My original problem is that I add dynamic content to header-includes using a lua filter (https://github.com/pandoc/lua-filters/pull/12). With the cli parameter -H/--include-in-header it gets always overwritten and there is no workaround to circumvent this. Merging of metadata was already implemented for yaml files and yaml blocks using left-union. I vote the same for -H/--include-in-header. -- 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/3b614a95-7ade-4fb3-bf79-39d63b51a038%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. [-- Attachment #1.2: Type: text/html, Size: 3526 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2018-02-01 7:17 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-10-29 3:18 Discussion needed—How should pandoc handle when meatada in YAML collide with command line option Kolen Cheung [not found] ` <836ca2d4-6e39-4f7e-b227-69dc06be6f15-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2016-10-29 17:24 ` BP Jonsson [not found] ` <CAFC_yuQZfyYuP6LzVtv02pVkr92Vx6zATosAdXbm+BCbxeTMMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-10-31 4:13 ` Kolen Cheung [not found] ` <bd8aea27-38c3-4ace-af2e-6603a64fb977-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2016-10-31 18:14 ` Melroch 2016-12-01 11:55 ` Kolen Cheung [not found] ` <CADAJKhBWjp7-7-JCrqZXnkaOw8xRtDDv-tCUos29=T1JOTOWkg@mail.gmail.com> [not found] ` <CADAJKhA7miFDtn5dOxtFw5VF7TwQMDiXs=8pnrKoOUuVhjoRgQ@mail.gmail.com> [not found] ` <CADAJKhA7miFDtn5dOxtFw5VF7TwQMDiXs=8pnrKoOUuVhjoRgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-12-02 15:36 ` Melroch [not found] ` <CADAJKhCfDzDaQYSn=iNzM0XXEpisontg=LxrOadmHD6_6aNriw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-12-02 22:42 ` BP Jonsson 2016-12-03 0:28 ` Kolen Cheung [not found] ` <089593aa-75c3-42fb-9b94-1cf0c01643cd-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2016-12-03 0:38 ` Melroch [not found] ` <CADAJKhCkSC80BR8NDbFKArmRR=80DxxRXQYeEVcBVhiCgxWgYw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-12-03 1:21 ` Kolen Cheung [not found] ` <f57e9537-1701-4e48-8d1f-c3d9c43af24f-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2016-12-04 22:32 ` Melroch [not found] ` <CADAJKhDHskio7KYbEo0yXMvLQL+WYYWyh_gO3HNqwCTVRTJB8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-12-05 1:13 ` Kolen Cheung [not found] ` <8d8167cf-894c-4dd4-8b1b-1fe8b49b3258-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2017-01-17 17:54 ` mb21 [not found] ` <aed26351-9296-42f2-9711-94f029fb8b0d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2017-01-17 18:24 ` Kolen Cheung [not found] ` <7bcf5965-a2fa-41d5-817e-bc27aeba7c7d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2017-01-18 11:03 ` John MacFarlane 2017-01-18 11:25 ` John MacFarlane [not found] ` <20170118112524.GB44054-BKjuZOBx5Kn2N3qrpRCZGbhGAdq7xJNKhPhL2mjWHbk@public.gmane.org> 2017-01-23 10:13 ` mb21 [not found] ` <679bf64d-3de1-48e3-b738-0e9059c69a98-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2017-01-23 10:23 ` John MacFarlane [not found] ` <20170123102338.GL1889-BKjuZOBx5Kn2N3qrpRCZGbhGAdq7xJNKhPhL2mjWHbk@public.gmane.org> 2017-01-23 10:38 ` mb21 [not found] ` <5038f42b-77c9-4e63-a1ed-fbea1342828c-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> 2017-01-23 10:50 ` Kolen Cheung 2017-01-17 18:47 ` Albert Krewinkel 2017-01-18 11:23 ` John MacFarlane 2018-02-01 7:17 ` tolot27
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).