Settings

[rschroll]

Right now, the compilation process is hard-coded into LiTeX. Things are set up to allow running an arbitrary set of commands, with arguments based on the input file name, but there's no way for the user to access this.

We should allow both global and local settings. The global settings can probably be set in the user's behavior file, but I'm not so sure where to set the local ones. They could be in

• a per directory config file, .litexrc or similar. These settings would automatically apply to all tex files in (and under?) that directory. This would be easiest to set up and use, I suspect.
• project files that explicitly state to which files the settings apply. Would allow for more power in terms of which file goes where, but would be more difficult to implement.
• per file settings, stored in comments. Ultimate specificity, but a pain to maintain. Would require parsing each file.

I'm leaning towards the first right now, since it's the easiest and still rather powerful.

The settings should include:

• The compilation command. A list of strings to be run, with replacements for the current file name. Could be a single command (pdflatex), several (latex, dvips, ps2pdf), or triggering a build system (make).
• The input file name. Either based off the current file name, or a fixed value, in case your project is split into several input files. Also would be useful when editing bibtex files, or similar, but I'm not sure exactly how these cases interact.
• The output file name, in case it isn't input.pdf.

The case I'm worried about is when you have several tex files in the same directory. Each can be compiled separately, but you also have a main one that gathers them altogether into one. There are other auxiliary files that can't be compiled alone, so when they should trigger a build of the full thing. How do we make it just work, no matter which file is open?

[bilderbuchi]

I also lean towards a litexrc file, applying to all tex files in and under. I don't know if you would need more granularity for subdirectories, but if so, you could go the route of .gitignore, where .gitignore files in deeper directories override settings in their parent folders' .gitignore files.
Regarding the "master document" problem - I agree, this will be necessary. This could of course live in .litexrc as a key-value pair. Kile, for example, has a [General] section with an entry masterDocument=someFile.tex.

Settings:
Yes, a list of commands would be best, with a number of replacement characters. This offers the most flexibility for users, if they want to use a chain of commands, make, or whatever.
If it's of interest, here's the build chain of my latest bigger Latex project (thesis), basically copy-paste from Kile settings dialog.

• makeindex '%S.nlo' -s my_nomentbl.ist -o '%S.nls'
• pdflatex -src-specials -synctex=1 -interaction=nonstopmode '%source'
• bibtex '%S'
• forwardpdf: /home/cbuchner/scripts/forwardokularnew.sh '%absolute_target' (a custom script to get forward sync working)
  Also, lessons learned, Kile does not store these settings in the project folder, which is a major drawback if you have heavily customized build chains and several projects, so +1 on storing this in a local .litexrc.

[rschroll]

Well, if two of us agree that the per-directory approach is the right one, that's good enough for me. I'm not so sure about settings automatically propagating to subdirectories. In addition to being more work, it's not entirely clear to me about how we should handle relative paths and working directories in that case. If you have a setup with multiple levels of directories, maybe it'd be better to use make, latexmk, or rubber.

Light Table actually has two different evaluation commands, Ctrl-Enter and Ctrl-Shift-Enter by default. We could allow separate compilation commands for each, so one could do just the tex file you're editing, while the other does a whole project.

[bilderbuchi]

In my experience, if you have a project with multiple tex files (and a master document), it doesn't make sense to compile the sub-documents. They won't be legal latex anyway, because they just get \included in the master doc. So I don't see a use for splitting the commands like this (that's just my opinion/workflow, could be wrong).

[rschroll]

@bilderbuchi: You may be interested in the docmute package, which lets you include full documents in a master document.

[bilderbuchi]

Ah, didn't know that package. I don't really know why I would do that, though (e.g. for chapters of a book in separate files it makes no sense). I'm sure someone finds/found it useful, though. :-)