Skip to content

Use llmk.toml as default.config - #29

Closed
Freed-Wu wants to merge 1 commit into
wtsnjp:masterfrom
Freed-Wu:project
Closed

Freed-Wu wants to merge 1 commit into
wtsnjp:masterfrom
Freed-Wu:project

Conversation

@Freed-Wu

Copy link
Copy Markdown
Contributor

Fix #23

User can define a default sequences in llmk.toml
Then use

% +++
% sequences = ["..."]
% +++

to override the default sequences for a specific document.

@wtsnjp

wtsnjp commented Oct 22, 2026

Copy link
Copy Markdown
Owner

Thanks for the proposal. Writing default settings in an external config file (llmk.toml) and specifying which one to use in the TOML field of a LaTeX document isn't a bad idea, but I'm cautious about adopting it in llmk.

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 llmk.toml or the TOML field, and this is intentional. Your proposal is convenient, but it would change this principle, so I can't accept it at this point.

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 llmk.toml rather than in the TOML fields). If you could propose such an approach in Issue #23, I'd be happy to consider it.

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.

@wtsnjp

wtsnjp commented Oct 22, 2026

Copy link
Copy Markdown
Owner

For example, one possibility might be to prepare multiple sequences and temporarily select one from the command line, in combination with the --temporary flag discussed in Issue #25 and introduced in PR #26.

@Freed-Wu

Freed-Wu commented Oct 22, 2026 •

Copy link
Copy Markdown
Contributor Author

I know your meaning: user must write config in one place, llmk.toml or main.tex's % +++. not both (project settings in llmk.toml, and % +++ to override it)

So for a project containging XXX-slides.tex and XXX-article.tex:

XXX-slides.tex:

\input{main}

XXX-article.tex:

\input{main}

main.tex:

\documentclass{beamerswitch}
% ...

We hope

# compile slides and article
llmk
# only compile slides
llmk XXX-slides.tex
# only compile article
llmk XXX-article.tex

We must:

llmk.toml:

source = ["XXX-article.tex", "XXX-slides.tex"]
output_directory = "build"

[programs.bibtex]
target = "main.bib"

XXX-slides.tex:

% +++
% output_directory = "build"
% [programs.bibtex]
% target = "main.bib"
% +++
\input{main}

XXX-article.tex:

% +++
% output_directory = "build"
% [programs.bibtex]
% target = "main.bib"
% +++
\input{main}

The configuration must be write every times. Right?

If we support use llmk.toml as default config, we don't need write any % +++.

@wtsnjp

wtsnjp commented Oct 22, 2026

Copy link
Copy Markdown
Owner

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 llmk.toml, we could let the TOML field defer to it entirely.

Concretely, I'm thinking of a new key that is effective only in TOML fields (the mirror image of source, which is effective only in llmk.toml):

% +++
% use_llmk_toml = true
% +++
\documentclass{article}

When this key is set to true, llmk takes the workflow for that file from llmk.toml in the same directory, exactly as if it had been run without arguments. The key point is that no other key may appear in the same TOML field; otherwise llmk raises an error. This way the complete configuration still lives in one place (llmk.toml), and the TOML field only states explicitly where to find it. Nothing gets merged, so there is no ambiguity about precedence.

A few details that would need to be settled:

  • Relation to source. When llmk foo.tex is run and foo.tex defers to llmk.toml, I'm inclined to require that foo.tex is listed in the source array of llmk.toml, and to raise an error otherwise. This keeps llmk.toml as the complete and authoritative description.
  • Missing llmk.toml. This should be an error, not a fallback to the default configuration.
  • llmk_version. I'd lean towards not making an exception for it, so that the rule "this key must be alone" stays simple to explain.
  • Other magic comment formats. This would be a TOML-field-only feature; TeXShop directives and the shebang-like directive cannot express it.

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.

@Freed-Wu

Copy link
Copy Markdown
Contributor Author

So if use_llmk_toml = true, the %+++ will be ignored and llmk will only read llmk.toml except source, really?

XXX-article.tex:

% +++
% use_llmk_toml = true
% output_directory = "build2"
% [programs.bibtex]
% target = "main2.bib"
% +++
\input{main}

llmk XXX-article.tex will ignore output_directory = "build2" and target = "main2.bib".
Right?

@wtsnjp

wtsnjp commented Oct 22, 2026

Copy link
Copy Markdown
Owner

Yes, that's right, with one refinement. Following the principle of keeping the workflow definition in one place, once use_llmk_toml = true appears in a TOML field, every other setting in that field is disregarded. More precisely, there are two options: ignore them with a warning, or raise an error. I'd prefer an error, since it tells the user clearly that this usage does not work as they might expect. So in your example, llmk XXX-article.tex would fail because of output_directory and programs.bibtex.target, rather than silently ignoring them.

As for source: it is still read, but only to check that the given file (here XXX-article.tex) is listed in it. Everything else, including the sequence and the programs table, comes from llmk.toml.

If you want to apply a different workflow (in particular a different sequence) to each source, e.g. XXX-article.tex and XXX-slides.tex, that would require an extension to the llmk.toml specification so that per-source workflows can be expressed there. With use_llmk_toml, the idea is of course that the workflow bound to that particular source in llmk.toml is the one that gets executed. That extension is what I'd like to discuss in #23.

@Freed-Wu

Copy link
Copy Markdown
Contributor Author

Perhaps we can use other key name, such as:

XXX-article.tex:

% +++
% config = "llmk.toml"
% +++
\input{main}

Which even allow user use different toml files for different documents.

XXX-slides.tex:

% +++
% config = "slides-llmk.toml"
% +++
\input{main}

@wtsnjp

wtsnjp commented Oct 22, 2026

Copy link
Copy Markdown
Owner

I like that idea. Let me think about it for a bit

@Freed-Wu

Copy link
Copy Markdown
Contributor Author

I like that idea. Let me think about it for a bit

Good. So let we close this PR now.

@Freed-Wu Freed-Wu closed this Oct 22, 2026
@Freed-Wu
Freed-Wu deleted the project branch October 22, 2026 10:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

How can I add 2 sequences?

2 participants