What reasons (if any) are there for compiling in interactive mode?

Question

I'm a command-line junkie and often compile with a simple pdflatex filename.tex from a terminal, and I forget (or am too lazy) to type -interaction=nonstopmode or interaction=batchmode. Hence, when I encounter errors, I've given the interactive prompt, which I find confusing and unintuitive, and usually get out of it as quick as possible with 'q'.

Does anyone make use of the interactive prompts, and find them useful or advantageous as opposed to simply parsing the .log file, fixing the problem and recompiling from the beginning? Is it worth learning the interactive system?

If I had to guess, I'd suppose the interactive mode hasn't changed much since the early days of TeX, when it took much longer to compile a document, and you might not want to start from scratch when you made one tiny mistake. But now that compilation takes seconds at most, is there a compelling reason ever to use interactive mode?

I ask partly because I'm on the verge of putting alias pdflatex='pdflatex -interaction=batchmode' in my .bashrc, but I wonder whether anyone thinks I'd be losing anything by doing so. If so, is there any free documentation out there about how to use the interactive system? (Or am I overthinking/overcomplicating it?)

Answer 1

I, too, think that the interactive mode was important when the edit-compile-test cycle was very long and one couldn't afford to start over for each mistake.

However, today we are more accustomed to the Unix style of error reporting, where an utility would print the error and exit immediately. Luckily, there is a command line switch combination that does precisely that:

pdflatex -interaction=nonstopmode -halt-on-error

With this command line, only the first error is printed on the terminal, and control is returned to the shell. The only disadvantage is that you can't type H anymore to read the error help — but if you have at least some experience with LaTeX, you will not need the error help text very often.

Answer 2

I sometimes use the interaction mode for debugging. You can insert code by using I in the prompt. Then I often write \makeatletter\show\@some@internal@macro or something similar. The \show will get you another prompt and can again use I to add more code. I find this faster than placing this debug code in the document if it is just done once anyway. Otherwise you have to abort, edit your code, compile and change your code back again.

Any real fixes of the code I do in the original file, not in the interactive mode, otherwise it would get lost.

Note that you could define aliases (Unix/Linux) or Shell/Batch scripts to call pdflatex in nonstopmode or batchmode. I also use Makefiles as mentioned by Raphink. Also latexmk is very useful (needs the -pdf option for PDF output). Finally there are the \nonstopmode and \batchmode macros (actually primitives) which can be used in the document to change to that mode.

Answer 3

Instead of setting an alias like you're doing, I usually write a Makefile for projects, with something like:

TEXINPUTS=microtype:

%.pdf: %.tex
        TEXINPUTS=$(TEXINPUTS) xelatex -shell-escape -interaction=batchmode $*
        TEXINPUTS=$(TEXINPUTS) xelatex -shell-escape -interaction=batchmode $*

so I just type make mydocument.pdf to build my PDFs. Whenever I have errors, I like to relaunch the command without the -interaction=batchmode bit so that it stops interactively and I can see exactly where the code fails. I do not use the interactive console per se though, I only press X most of the time.

Answer 4

I'm not a command line junkie (I'm starting almost every compilation through shortcuts or buttons in winedt) but I'm always running latex in interactive mode. Also I'm not using the integrated console of my editor instead I have setup winedt so that it pops up the normal command window and pause at the end of the run. This means at every error/halt I have to decide how to react (depending on the error with enter, x or sometimes s), can use \show in my document and can check fonts, file size and the other informations you get at the end without having to open the log.

I'm not doing it to save time but because I get more control, more informations and can't forget to correct an error. (Imho at least newbies should avoid \scrollmode. It leads them to ignore errors as long as they are not fatal.)

Answer 5

if there were only one error in the file being processed, a batch approach could be appropriate. but if there is more than one error, using the interactive approach permits one to correct the error interactively and continue on, find other errors, and potentially correct them as well so the job completes. (one typical error is the misspelling of a command name; often a simple in-line \let or definition will take care of multiple instances of the same error.) then go back, fix what's reported in the log (making sure to check for multiple instances of whatever misspelling caused you to enter an interactive workaround), and you're on your way.

in the case of a really fatal error, where one error triggers many others and can't be corrected simply in-line, it's time to quit, go back to the log, fix the known problems, and restart. in documents with heavy math, this process is much simpler and quicker than slogging through an "incomplete" log -- tex dropped out after too many errors reported -- and iterating in batch mode. in fact, the current speed of compilation makes this approach even more attractive than it used to be in the bad old days of tortoise-speed machines.

once the file is clean, batch mode is appropriate for multiple runs to generate good citation links and final index and table of contents.

i'm a command-line junkie too, so that's not a relevant consideration here.

Answer 6

I forget (or am too lazy) to type -interaction=nonstopmode or interaction=batchmode.

Or in my case, I didn't bother to read the manual to find that such an option exists. There is an alternative that works quite nicely for makefiles: Force latex (or in my case pdflatex) to receive input from /dev/null rather than the terminal. This of course gives an immediate EOF, which in turn results in an ! Emergency stop in latex.

$(PDF_FILES): %.pdf : %.tex
  cat /dev/null | $(PDFLATEX) $(basename $(@F)).tex
  cat /dev/null | $(PDFLATEX) $(basename $(@F)).tex