Compile project from file in subdirectory

[mokasin]

I have a project that is composed of a main file and inputed files from subdirectory like this

project
|- chap1
|  `- foo.tex
` main.tex

Is it currently possible to compile main.tex when foo.tex is opened without switching?

It would be nice, if the project evaluation would be aware of files in subdirectories.

[rschroll]

Yes, but it's not particularly optimal. If you edit the .litexrc file in project/chap1/, you can set the filename of one (or both) the compilation command's filename to "../main.tex". This will cause latex to be run on project/main.tex, with the working directory of project/.
If you have a non-default command in project/.litexrc, that will also need to be copied to project/chap1/.litexrc.

This does require you to put a .litexrc file in each of your subdirectories; if you have one for each chapter, that's going to get annoying when you want to update them. My best suggestion right now is to use a make script of some kind instead, but I welcome other ideas you may have.

My first though was to read all the .litexrc files on the path, starting at / and working all the way to the current directory. This would allow you to tweak the settings of parent directories. But it quickly gets confusing in which directory the latex command should be run. If the filename is set at one level, the command at a second, and the current file is at a third, where should latex be run?

A simpler approach would be to look to the parent directory only if there's no .litexrc file in the current directory. But it's still not entirely clear to me in which directory latex should be run. This could also cause problems when you have a document in a subdirectory of another that shouldn't share the build settings. (I do this with correspondence about a paper.) You'd have to make an empty .litexrc file to keep from inheriting the parent's settings, which is a bit non-obvious.

Perhaps we could make it somewhat more explicit and require a subdirectory's .litexrc file to have the text ".." to indicate that the parent's should be used. Or there may be tricks with symlinks we could play, though that is asking for cross-platform headaches.

TL;DR: It's possible, but not pretty. If you have suggestions of how to make it prettier, I'd love to hear them.

[rschroll]

There does seem to be an issue with synctex in this setup. I think I have it figured out.

[mokasin]

Is there a case of a LaTeX source file, that can be compiled without a documentclass and/or a document environment? Because if not, than this would be a pretty strong indication, if the current file can be directly compiled or not. You'd have 'parse' the code though.

Than it would be sound to travel up the source tree, until it a compilable file is found (or respectively a .literc that marks it.)

Obviously that would require a standard source tree layout, where the LaTeX file is always above or at the same level of all it's children files. Which is a sensible assumption (for every other file from somerwhere else, that might be imported to other projects to, it has ambiguous parents anyway).

If the filename is set at one level, the command at a second, and the current file is at a third, where should latex be run?

I don't really get what you mean by this. Are you talking about some kind of configuration inheritance from parent directories?

Hope it's understandable. Pretty tired right now ;).

[rschroll]

On Mon, Aug 25, 2014 at 4:43 PM, mokasin notifications@github.com wrote:

Is there a case of a LaTeX source file, that can be compiled without a documentclass and/or a document environment? Because if not, than this would be a pretty strong indication, if the current file can be directly compiled or not. You'd have 'parse' the code though.

This is not a bad idea. It wouldn't be a perfect solution, as it is possible to include a file that has a documentclass, but it could be a nice 90% solution. A variation on this idea would be to have a special comment that would tell LiTeX to look elsewhere for the LiTeX file.

There's a related feature that's already in the code -- if you trigger compilation from a file with an extension other than .tex or .latex, LiTeX will use that last .tex (or .latex) file to figure out the compilation command that should be run. I put this in to allow you to compile while editing BibTeX files, for example, but this would be (ab)used to help here by giving the included files a .texf extension.
There are two problems with this approach: 1) The parent tex file has to be compiled at the beginning of the session, so LiTeX knows which it is. 2) It forces you to adapt to the tool, which isn't how things should work.

I'm going to let this idea stew for a few days. If you come up with any refinements, please comment. And if you don't hear from me in a few days, remind me about this!

[rschroll]

I'm a bit worried that this could make things confusing for people using formats other than LaTeX. Although LiTeX is primarily aimed at LaTeX files, it could be used with plain TeX, ConTeXt, or any pandoc file set to compile to PDF. These would also trigger the documentclass detection code, despite being perfectly able to compile by themselves.
We could add additional tests, but I fear that this would become dangerously implicit.

What do you think about the comment idea? I'm thinking of searching the first n lines of the document for something like %LITEX_FILENAME ../main.tex Not only could that solve this problem, it'd offer an alternative to some uses of .litexrc files

[mokasin]

Aren't there to different build commands in Lightbox? One for the current file and one for the project?

I don't particular like the idea with the comments. Because I don't like editor specific boilerplate in my source code in general. But I suppose, that's a preference.

[rschroll]

Sorry -- I forgot about this bug. Unfortunately, looking over it again, I'm not seeing any great solutions.

LightTable does have two build commands, and Litex does let you use both. But despite the fact that I've named them suggestively as "file" and "project", I want them to behave the same, so the user can do whatever they like with them.

You might consider using the global litexrc file to specify compilation commands for the subdirectories and then override those with a local .litexrc file in the parent directory. This may not scale when you have multiple projects, though. Or you could make a single rc file for the subdirectories in the parent directory, and then make symlinks to it in each of the child directories. This would take a bit of work to set up, but it'd let you change the compilation settings for all the subdirectories easily.

Your best bet, though, is probably using a build system that gives you more power to specify how everything should work.

I'll leave the bug open in case anyone has other solutions to propose, but please don't count on that happening.