Repository navigation
Conversation
|
Thanks for the proposal. Writing default settings in an external config file ( The reason is that llmk isn't meant to be just a tool for automating the processing of LaTeX documents; one of its goals is to provide a way to describe how a LaTeX document should be processed unambiguously, in a single place. That's why, under the current specification, users need to write the complete configuration in either I think there could be a way to provide multiple variable sequences in separate files while still requiring users to write their configuration in one place (in such cases, users would probably put all their settings in For changes like this that touch the fundamental design of how workflows are described, I think it's better to discuss the direction first, before jumping into a prototype implementation. I'm sorry, since you've already put in the work to implement this (and I really appreciate your effort), but I hope you understand. |
|
I know your meaning: user must write config in one place, So for a project containging
\input{main}
\input{main}
\documentclass{beamerswitch}
% ...We hope # compile slides and article
llmk
# only compile slides
llmk XXX-slides.tex
# only compile article
llmk XXX-article.texWe must:
source = ["XXX-article.tex", "XXX-slides.tex"]
output_directory = "build"
[programs.bibtex]
target = "main.bib"
% +++
% output_directory = "build"
% [programs.bibtex]
% target = "main.bib"
% +++
\input{main}
% +++
% output_directory = "build"
% [programs.bibtex]
% target = "main.bib"
% +++
\input{main}The configuration must be write every times. Right? If we support use |
|
Thinking about this a bit more, there might be a way to support your use case without giving up the single-source principle. Rather than having the TOML field override parts of Concretely, I'm thinking of a new key that is effective only in TOML fields (the mirror image of % +++
% use_llmk_toml = true
% +++
\documentclass{article}When this key is set to A few details that would need to be settled:
Selecting one of several named workflows (closer to what your PR was aiming at) could then be built on top of this later, as a separate discussion. I'd be happy to hear what you think. |
|
So if
% +++
% use_llmk_toml = true
% output_directory = "build2"
% [programs.bibtex]
% target = "main2.bib"
% +++
\input{main}
|
|
Yes, that's right, with one refinement. Following the principle of keeping the workflow definition in one place, once As for If you want to apply a different workflow (in particular a different sequence) to each source, e.g. |
|
Perhaps we can use other key name, such as:
% +++
% config = "llmk.toml"
% +++
\input{main}Which even allow user use different toml files for different documents.
% +++
% config = "slides-llmk.toml"
% +++
\input{main} |
|
I like that idea. Let me think about it for a bit |
Good. So let we close this PR now. |
Fix #23
User can define a default sequences in
llmk.tomlThen use
to override the default sequences for a specific document.