#! include directive

[syxolk]

Using the latex command \input{chapter_1_indentex.tex} or # input: chapter_1_indentex.tex, I can already include other transpiled files from my main file. But it seems somehow odd to include tex files from indentex files.

My feature request: Add a special #! include <file.inden.tex> directive. The transpiler will then try to find the referenced file, transpiles it and replaces the directive with the transpiled content. This is of course recursive, meaning that included files may also include files. The search path is relative to the file where the include was found.

Example: main.inden.tex

# document:
  #! include chapter

chapter.inden.tex

# section: My chapter
Lorem ipsum

This is transpiled to main_indentex.tex:

\begin{document}
  \section{My chapter}
  Lorem ipsum
\end{document}

Note: The transpiler emits only a single tex-file.

[mp4096]

Thank you for the idea and the feature request!

I can already include other transpiled files from my main file. But it seems somehow odd to include tex files from indentex files.

My typical usage (see below) / best practice is to have a root plain LaTeX document which includes indentex-transpiled files. That's why I haven't encountered this papercut before.

The search path is relative to the file where the include was found.

Unfortunately, this clashes with standard LaTeX behaviour. LaTeX interprets all paths as relative to the root document. Suppose you have something like this:

parent/
|--foo.tex
+--child/
   |--bar.tex
   +--qux.tex

and foo.tex contains \input{./child/bar}. Now if you want to include qux.tex from bar.tex, you must write \input{./child/qux} in bar.tex!

Now if you want to build a kind of recursive tree of relative paths, you should use the import package and do something like this:

In foo.tex:

\import{./child/}{bar}

In bar.tex

\input{qux}

So I'm not sure if this is the behaviour you want to have.

---

This is my typical root file:

\documentclass[a4paper, 11pt, twoside, fleqn, english]{book}

\input{setup/packages}
\input{setup/metadata}
\input{setup/customcommands}
\input{setup/settings}

\begin{document}

  \input{auxfiles/__frontMatter}

  % Main matter
  \mainmatter
  \pagestyle{fancy}
  \include{chapters/foo_indentex}
  \include{chapters/bar_indentex}

  \input{auxfiles/__backMatter}

\end{document}

---

1/2

[mp4096]

Note: The transpiler emits only a single tex-file.

I think this will curtail some LaTeX features like \includeonly{} that are crucial when dealing with huge documents.

---

So what do we have? To be honest, as a self-proclaimed BDFL of indentex, I'd like to decline this feature request.

When I conceived indentex, I had very concrete goals in mind:

1. indentex should be more concise than LaTeX
2. indentex should reduce cognitional overhead when reading source code
3. indentex should allow zero-cost dropping down to plain LaTeX anytime
4. indentex should transpile to plain LaTeX so that you can upload transpiled source code to the publisher or share it with your colleagues

1, 2 and 3 can be summarised to 'less painful LaTeX'.

I fear that implementing this feature request will lead to a lot of error-prone, hard-to-implement-correctly code (e.g. what to do with symlinks, cross-platform madness, error handling etc.). On the other side, the advantages are not sooo big... I do not think this

#! include foobar

is that much easier to read than this:

# include: foobar_indentex

Discuss!

---

2/2

[syxolk]

My initial intention for this was to reduce the number of generated tex files or at least to not see them anymore. My first idea was to move them to the latex.out folder that is already used by latexrun to hide all those log, aux and toc files. But then all references to external files like graphics don't work anymore. So, I came up with the special include command.

btw: I never used \includeonly before to reduce compilation time (would have probably helped a lot, sigh). And yes, this feature request would destroy that.

[mp4096]

My initial intention for this was to reduce the number of generated tex files or at least to not see them anymore.

I personally do want to see them! Before we have sourcemaps, I don't have any other way to know where exactly pdflatex runs into an error.

But then all references to external files like graphics don't work anymore.

Uhm, if you do not move the root document (or write it in plain LaTeX), everything should be fine (see the example above).

[syxolk]

I still think this is a good idea but it's a lot to implement for little gain. Basically we would reimplement something that's already covered by LaTeX.