5

I have a rather large document (about 150~200 pages) with plenty of cross-references. I can, of course, use \include and \includeonly, but I do not only have new chapters, I also use \input for smaller pieces I have written (which are still rather long) and they should not invoke a clearpage. So, disabling those parts will additionally get plenty of (??).

Sure, I can get out the relevant pieces, but I don't like that type of workflow. Are there good references what might be a good workflow to write a PhD thesis or a book?

I am using a scons script to run the required programs often enough (biber as well).

The reason I compile I to see if it looks good now, or to make it easier for me to read the things I have typed. I am using emacs, so perhaps preview-latex can help me, but that seems to me as a rather ugly hack in the way it is generated (and slow). Is anybody aware of using MathJax for preview-latex? They would not have to go through the latex compiler.

But using these things still make the compile last way too long. So my question is perhaps a bit strange and displays my tremendous ignorance on these matters, but...

The question: I see there are many projects like LuaTeX, XeTeX and so on which seem to improve on one of the disadvantages of pdftex. Are there also versions which have a saner error handling? For instance, are there versions which do not require so many auxiliary files and store ".aux" in perhaps an SQLite DB? I can imagine that the user interactive part during compile was very useful when computers were slow and memory was expensive, but nowadays this does not seem so useful to me (and most editors seem to disable it...). Often, I have to delete the .aux because otherwise I keep compile errors after I made a mistake. Am I doing something wrong?

What is the big problem for having a better handling of errors in LaTeX? I am interested in the problem from a programming point of view, I would like to understand the compilation in more detail.

Last... Are there also drivers that compile into some kind of "intermediate format"? The thing would be that this should support the pdf features but still be rather easily readable, for the purpose of having at compile time the option to do a diff with the old code, study what needs to be regenerated and insert that part. In the end the page breaks could be regenerated, but if I am just working on the document a "lazy" compile which skips this step would be very useful.

I am not sure what kind of answer I am looking for. "You are doing it wrrrrong" is fine as well. Actually, that would be the best as then I would not have to start programming instead of working on my thesis and teach calculus 8-).

JT_NL
  • 2,153
  • Are you possibly including a lot of large graphics files? If so, adding the draft option will speed up compilation by inserting "dummy" images instead of the real ones. Do you have a lot of per-chapter bibliographies? If so, assuming they've been generated correctly once, you probably can dispense with re-generating them over and over again, and wait till the near-final version to (re-)create them. – Mico Oct 21 '12 at 14:51
  • 3
    Related: How can I speed up LaTeX compilation? – Werner Oct 21 '12 at 14:59
  • 1
    @Mico No graphics. But I do have chapter bibliographies. Are there methods that only regenerate new things and not the run the complete chain again? I am already using the draft mode, by the way. – JT_NL Oct 21 '12 at 15:01
  • you could add the draft option and just compile into dvi mode using latex myfile.tex; the dvi file is the "intermediate" file format you describe – cmhughes Oct 21 '12 at 15:32
  • @cmhughes Does .dvi support all the pdf features too? Perhaps, I do not need those for the draft, but I use a pdf viewer, perhaps due to inertia. Also, it might be the case that I have .pdf images. Will that work? – JT_NL Oct 21 '12 at 15:55
  • @JonasTeuwen nope, '.dvi' definitely does not support all the features, and will not render all of your images; if you use draft mode then the images wouldn't be a problem :) – cmhughes Oct 21 '12 at 15:58
  • Right, that will help already a bit :-). But, I was more like thinking about some format which makes it easy to only recompile small pieces instead of the complete thing :-). – JT_NL Oct 21 '12 at 16:05
  • Seriously: Get a faster computer. – Martin Schröder Oct 22 '12 at 06:35
  • @MartinSchröder I would like to. But, now it is a core 2 duo and it seems strange that compiling a document should last that long on such a computer :-). Of course, that is a solution, and perhaps not such a bad one. But I feel like I should be able to use the available resources better before I throw more iron at it mmmkay. Also, if I'm at my office, I doubt they will grant me a new computer just because my document takes too long to compile. "Word doesn't have any problems!" – JT_NL Oct 22 '12 at 08:19
  • 2
    @JonasTeuwen: How long is "too long"? Remember: The compilations of the TeXbook bei Knuth in 1986 probably took hours - now we can compile the TeXbook in seconds. – Martin Schröder Oct 22 '12 at 08:52
  • 1
    About twenty to thirty seconds perhaps. Which aspect makes the question "not real"? The workflow in 1986 was probably way different than nowadays when I want to see rather 1-1 what I am doing. Anyway, for one of the closers, what aspects make it not a real question? "overly broad" is the only thing I might agree with for now, any others are then due to my lack of explaining the issue properly. – JT_NL Oct 22 '12 at 13:43
  • I can see why this is closed but also I can see that you also have some discomfort with it, if you feel like it we can repoen it but the question is really unanswerable and you also mention that you are not even sure about it. Most of the details are higher level additions and use extensively the TeX as the main engine. So there is not much without altering TeX itself. Instead of scons(?) I can propose to-be-released arara 3.0. See this http://vimeo.com/51860022 for a (maybe) better workflow alternative. – percusse Oct 22 '12 at 23:26
  • @percusse Thanks! I'll see if I can split up the question in smaller much more concrete questions. – JT_NL Oct 23 '12 at 12:20

0 Answers0