-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Template snippet won't be resolved using includes
such as -H
, -B
, -A
#3138
Comments
I remember some earlier discussion on this topic, but cannot find the threads ... For some reasons the @jgm Can you remember the reasons for this? It certainly would make things easier, if pandoc would include the |
In general it wouldn't be desirable to recursively resolve +++ Carsten Gips [Oct 03 16 02:21 ]:
|
Will you consider giving an option to control this behavior? To borrow an analogy, in Jekyll, if and only if a file starts with a YAML front matter, it will be processed including the liquid template language. So if we don't want to introduce more command line option, we can do it exactly the same way. Since a YAML front matter will not be valid (be it html, tex, etc.), it differentiates the file I want to be processed as template or plain. |
To give more details on the use case behind the issue, an example is ickc/pandoc-amsthm. That "package" is not just a filter, but a filter comes with templates. Both are required for it to work. (Basically it defines the amsthm through YAML front matter. Then through the templates, it auto-generates the necessary header/preamble to define the amsthm in HTML/TeX. Then the filter transform pandoc native div into LaTeX environment.) What I did is I includes templates for TeX and HTML output, but then that overly restricted its use since people might need their only custom template. I then created a fragment that include the codes related to amsthm only, and said it could be used to create a custom template. But that's a manual process. If I want to mention a way to do it automatically, currently I need to say something like: MD=$(<INPUT.md)
echo "$MD" | pandoc --include-in-header=<(echo "$MD" | pandoc --template=pandoc-amsthm.EXT) -o "OUTPUT.EXT" # where EXT is tex/html While it is a nice trick, it seems very daunting. (What I wanted to do is to provide a very straightforward way to deal with amsthm in pandoc. So the last thing I want is to make it looks daunting.) |
If you include Text.Pandoc.Templates in your filter, |
Thanks for the info. Seems like it should be something I use. I didn't see it used in the example from jgm/pandocfilters, so I didn't know it before. But the point is still the same though. For example, there's another template snippet I personally used like this: $if(ucharclasses)$
\usepackage[Latin$if(ucharclassesgreek)$,Greek$endif$$if(ucharclasseshebrew)$,Hebrew$endif$]{ucharclasses}
\usepackage{xltxtra,xunicode}
\usepackage{unicode-math}
\newcommand{\latinfont}{\renewcommand\rmdefault{lmr}\renewcommand\sfdefault{lmss}\renewcommand\ttdefault{lmtt}\defaultfontfeatures[\rmfamily,\sffamily]{Ligatures=TeX}}
\setTransitionsForLatin{\latinfont}{}
$if(ucharclassesgreek)$
\newfontfamily\greekfont{$ucharclassesgreekfont$}
\setTransitionsForGreek{\greekfont}{}
$endif$
$if(ucharclasseshebrew)$
\newfontfamily\hebrewfont{$ucharclasseshebrewfont$}
\setTransitionsForGreek{\hebrewfont\setRTL}{\setLTR}
\usepackage{bidi}
$endif$
$else$
$endif$ ---
ucharclasses: true
ucharclassesgreek: True
ucharclassesgreekfont: Cardo
ucharclasseshebrew: True
ucharclasseshebrewfont: Cardo
... This doesn't involve a filter, so if I want to distribute this snippet but not a whole template, the "round trip" trick of using pandoc twice is needed. The point is if there's an option to recursively resolve the template into the includes, then we can have a lot of "pandoc-extras" not in the form of filters but template snippet too. |
Does that requires Haskell? Or is it supported in pandocfilters? |
I encounter a related issue: If in command line, and in the md file's yaml: header-includes:
- \usepackage{siunitx} The YAML's header-includes will be overridden. I know the manual specifically said that the command line option will override YAML metadata. But on the other hand, since head-include is a repeatable argument, it seems to be within expectation for pandoc to combine both (YAML and command line's header-includes). This is kind of related to this issue, in the sense that it's an effort to shatter header-includes/templates into snippets. But on the other hand, the need of sanitizing codes might be behind the idea. And of course if the behavior is changed, backward compatibility would be an issue. Are there currently ways to have header-include in both command line and YAML? |
Note this: % echo "" | pandoc -t native -s -M foo=1 -M foo=2 If you specify foo multiple times on the command line, you However, it's possible that it would break some workflows. +++ ickc [Oct 13 16 20:17 ]:
|
I will open a thread there discussing this. Do you also want to discuss about the recursive template behavior, or is it settled and won't be changed? |
I opened a pandoc-discuss about the repeated metadata across YAML and command-line in Discussion needed—How should pandoc handle when meatada in YAML collide with command line option - Google Groups. Regarding recursive resolving templates, I'm thinking about if it is possible to have a command line option similar to |
Only this week I stumbled over exactly this behavior while using @ickc's amsthm template+filter: if a template-snippet is included using I fully agree with @icks rationale that straightforward template-snippets would alleviate the need for every user to build custom templates which then need constant merging with the upstream customized template. What if I want to use multiple customizations from multiple places? This will quickly get out of hand.. This finally got me thinking whether a
Of course, this is only a rough sketch, but it might make it super-simple for (multiple) extensions to be used independently. Clearly, it would need a little more differentiation, namely on where to include the snippet(s), so one idea might be to be able to have the snippets named after their position of inclusion:
Lastly, if plugins like these existed, we might eventually come up with something like a "package repository" for different modules/customizations/plugins, who knows... BTW: I didn't think of @ickc's round-trip "hack", pretty nifty! |
Hi, @xdbr, this partly is my bad, that didn't include all the necessary thing in the filter, but took a filter+templates approach (but it has an advantage of allowing one to tweak the template-snippet to their liking), see ickc/pandoc-amsthm#12. But I still agree there should be options to recursively resolve into template-snippet. Some simple things are very simple that only requires a template snippet, and the round-trip hack is too convoluted (@cagix told me this trick first). A possible way to make everyone happy and backward compatible is to have a command line option |
Hey @ickc: what do you actually think about the |
Hi, @xdbr, None of the followings are finalized yet:
Again, nothing promised, but they might happen. Stay tuned (in pandoc-discuss). If these are done, it would solves part of the problem above. For example, rather than giving pandoc an arg However, after all these, I think there's still a need to use template snippets (none of these directly addressed that), because something are too simple to be done via template snippet than writing a filter. I think the simplest way will be giving pandoc a new arg |
There aren't much discussion in Discussion needed—How should pandoc handle when meatada in YAML collide with command line option - Google Groups, may be because of a bad title. Do you think this should be changed? Allowing |
header-includes
cannot be used as template fragmentsincludes
such as -H
, -B
, -A
Just some updates: The few things I said before:
For the 2 related problems:
The first one is an old one (long before this issue is opened), and has known workaround as discussed above. So if it isn't going to be changed, I'm ok with it and we can close this issue. The second one is really a different issue, discussions here and in pandoc-discuss does not resulted in anything conclusive. And the main problem is there's no known simple workaround over this (except to preprocess the source markdown?). So if it is something you think it should be changed, I can open another issue about it. |
Closing in favor of #3139 for issue (2). |
I just realized I've probably made a mistake. I opened an issue in jgm/pandoc-templates#220. Probably I was working with templates and was in that repository so I opened there. But just now when I think about it, it is not an issue about any of the templates over there! The issue is about how pandoc handles templates. So it should probably be put here. I'm sorry about that. Here's the original post over there. There's a few discussions there already. And I am closing the issue over there. Sorry again!
The text was updated successfully, but these errors were encountered: