Exemplar case

I often have situations in which I must quickly write and print a report, within a short time. Some features of TeX allow me to work quickly. For example, with BibTeX, I can quickly add a source to an article.


However, some features of TeX seem to make the work inefficient. For e.g.: it can be difficult to make a tabular fit onto one page. Some problems are more serious, such as the syntax. One misplaced & or } and the whole document fails to compile.

  • What packages, supporting software, or tricks have saved you time?
  • What packages, settings, or work-flow process can help ensure that documents will always compile?

12 Answers 12


I have some thoughts:

  • Try to make sure you know beforehand (almost) everything your paper needs. Tables, figures, charts, and so forth. It's easier to write something when you already have an idea of what will be there afterwards. :)

  • Does your paper use a special document class, e.g. IEEEtran? When writing a paper, make sure to use the proper class/style, it will save time. Most conferences provide a LaTeX template to help you on this. If the template is not provided, stick with the good old article class and adjust the options according to your needs (size, columns, etc).

  • Make sure your file has the proper encoding. It might sound basic, but at least you won't have eventual problems with it. I once had a bad output, it took me an hour or so to figure out it was a simple encoding issue. :P

  • If you don't generate plots/figures/tables in your LaTeX code, always have their sources near you. If you draw diagrams with Dia, Inkscape, etc, create a src folder inside your project directory. Any changes will be easily found.

  • Speaking of directories, create a nice directory tree. I usually like to have everything I need inside my project directory. Folders are your friends. :)

  • I usually don't do this, but it's a personal taste. :) Make sure to have one big bib file with all your research references, from apple to zebra. It will save time to get citations in your papers. For every paper you write, use this file. If you need to add/remove/update stuff, it will be replicated to all your available papers.

  • Use your own code snippets. Things you use a lot, make sure to have them at your hands, e.g, a specific table environment, new commands, etc. You can also create a small package containing them, put it in the current folder or the personal tree. I have one for my math definitions, e.g, \Rset -> \mathbb{R}.

  • Use a nice editor/IDE. Learn what it can offer you. Code completion, standard code snippets, preview, you name it. There a post in our blog about some features we could use when writing our stuff. Also, other nice links include Charlie Tanksley’s series of posts on Vim and Seamus Bradley’s series of posts on emacs.

  • If your project is complex, create a build script. It can be a Makefile, a sh/bat file or even using latexmk, rubber or arara. If you need more super advanced stuff, use other tools (Perl/Python/Ruby) to make your life easier.

  • Comment and organize your code. I know we are talking about reducing time, but believe me, a good commented code helps a lot. Didier Verna's keynote at TUG2011 is very interesting; coding standards play an important role.

  • Know your tools. Check the formats they can export to - pdf, eps, ps, TikZ code.

  • Terminal is your friend. TeX Live has such great command line tools to help you, e.g, pdfcrop. ImageMagick also provides great solutions.

  • When in doubt, compile your projects a hundred times. :) Write a line, compile it. Better safe than sorry.

Hope it helps. :)

  • 1
    Anyone know where I can source Seamus Bradley’s series of posts on emacs? Seems like it's a bluehost holder now. Commented Aug 1, 2013 at 21:04
  • 1
    @PauloCereda The link 'charlietanksley.net/philtex/category/text-editors' doesn't work.
    – user42341
    Commented Jan 19, 2014 at 12:48
  • @user42341 What remains of PhilTeX can be found here; however, it seems that the relevant parts that Paulo linked to are missing.
    – Adam Liter
    Commented Apr 29, 2015 at 4:12
  • 1
    Using the WayBack Machine, the oldest version of the website before it went offline seems to be here.
    – Adam Liter
    Commented Apr 29, 2015 at 4:14

I regularly produce reports under pressure. There are two aspects to consider,

  1. Your own work habits
  2. The idiosyncrancies of TeX\LaTeX

The first is difficult to develop, whereas the second is techniques and building up on your knowledge of TeX.

First on work habits. Download focus booster, do a bit of reading on the pomodoro technique and ask yourself if you are a perfectionist; this often leads to procrastination; if you are a student or academic, self-test if you suffering from the common student syndrome. Get to know your productive times. Personally I went through all the syndromes at various stages of my life, nothing to worry about as long as you are aware of them. Most of the issues with productivity stem from trying to reach perfection. I would take an educated guess and say, that it is highly unlikely that anyone subscribing to this site who is not a perfectionist. Who else will worry about spacing and italics and formatting as we do, and spaces between subscripts and superscripts and fonts as we do? This aspect of yourself, you need to work on. A report that is to be read by a few people as for example a work progress report, does not need to be perfect. Maybe next time!

Now for some LaTeX techniques. Write what you have to say and then worry about the presentation. Don't do any editing relating to presentation unless you satisfied that the write-up is complete.

Compile often, is the best advice and given by a few people in other answers. Personally I try to minimize packages and if I can avoid it, especially hyperref.

Minimize mark-up within text blocks and don't incorporate any macros in your work unless you understand how they work. Minimize packages. Take a hey it works approach with your own macros and accept that other people might be better programmers than you and I. You writing a report and not a master class test in TeX programming. If you have any TikZ plots or graphs allow for anything up to three hours each, so here you can improve your productivity by spending a bit of time to develop a set of plots or diagrams common to your work.

As last words I would like to share with you my technique for editing (which I stole from Paul Halmos). Use the spiral technique. When you write Chapter 2, read and edit Chapter 1 and Chapter 2; when you finish with Chapter 3, read and edit Chapters 1,2 & 3. If you follow the technique when you are on the last Chapter you are done. This is also a good technique to adopt within a Chapter itself, just do the same with paragraphs.

There is no magic wand. To master anything you need to pay your 10,000 hours of effortful learning.

  • Why do you specially avoid hyperref?
    – Ricardo
    Commented May 7, 2013 at 5:05
  • 1
    Since these are printed hypelinking is unecessary. Also with hyperref you might have to compile one extra run.
    – yannisl
    Commented May 7, 2013 at 6:31

Ten minutes left to a hard deadline and LaTeX refuses to compile, yes.

Advice: When under pressure, compile often to realize any error instantly.

Apart from that, my main advice is never to come so close to hard deadlines. TeX was written by a man who worked in quietness without E-mail and probably his phone did not ring every five minutes. He forgot to implement a wizard-mode for the 21. century.

I myself mastered such troubles by employing a serious management for templates. I'm using Emacs as an editor (well, and as a calender, and for organising myself and . . .). There is an Emacs-package called YASnippets, which I can recommend. I've got some dozens of snippets, partially frames for whole files, partially something like "head of contract". Go and see, if you use Emacs. Otherwise dig what your editor offers.


For me, it's all about building up a code base and reusing it. If something is working then it's unlikely to break because TeX is so stable. This applies to macros, packages, new environments etc. Reuse whatever you can so you don't reinvent the wheel. Otherwise frequent compilations when you're coding something like a table. If you're on a mac and you're dealing with a large document, use LaTeXIT to do these separately for speed, then transplant code. On other systems you can use similar tools, or have a companion dummy document to do stuff like this in before putting it in the main document. If you're using TikZ, use externalise to speed compilations. Keep in mind my answer to your question on macros a while back.

Most of the time, you should not be doing anything special. What I mean is that for most users, they will be typing simple text and perhaps equations 95% of the time. Nothing is going to speed up your typing, so there's no improvement to be had there. For equations, you get fast through repetition. Some people use code completion tools, but I do it all manually because I can type fast enough to do that. I recommend keeping things simple. A good syntax highlighting editor with key bindings for compilation and flipping between source and output is invaluable, but you probably already use one.

I began using LaTeX with TeXnicCenter on windows, and it's good to have some extra tools until you learn the commands for the symbols and environments. Don't rely on your mouse. If it requires a mouse to click a button or navigate a menu, you're slowing yourself down. The sooner to can migrate to an editor with no clutter the better. Good examples or dedicated editors are Texmaker on Windows and Linux (although I still find it too cluttered) and I especially recommend TeXShop for Macs. Of course, you can use emacs, vim and other non-dedicated syntax-highlighting editors as well, and these come with bits to help you view and compile if you have a preference for one. If you know the key bindings for one of those, then use it because they're the fastest way of coding that I know of.

  • You can speed up your typing, both by practising and by using a good keyboard layout (tex.stackexchange.com/q/1979/86). Commented Nov 29, 2011 at 13:04
  • 3
    I'm not clicking on that link yet, but I'm guessing it says dvorak. If it does then I'm awarding myself an ice cream. Here goes...
    – qubyte
    Commented Nov 29, 2011 at 13:09
  • Aw. It's there but not nearly as high up as I imagined. Can't stand it anyway. I effectively have a different layout for different machines because I'm in Tokyo. The keyboard I bought with me is UK, this one is US and the one at work is Japanese.
    – qubyte
    Commented Nov 29, 2011 at 13:11
  • Mine's Norwegian (or is it Swedish?) which is almost what I'm used to but not quite and that almost catches me out whenever I use a machine where I don't have a decent xmodmap installed. Commented Nov 29, 2011 at 13:23
  • When will they learn that UK is more correcter?
    – qubyte
    Commented Nov 29, 2011 at 13:28

"Quickly" is always relative to personal habits and milage. You have to know your tools and their limitations be able to deal with them efficiently.

For me, LyX is a perfect match to quickly write documents with LaTeX typesetting qualities and BibTeX bibliography handling without having to deal to much with syntax errors, table development (for standard tables the table editor of LyX is pretty good), and looking up math symbols (the math editor is really good for those of us who do not write math all day: you can enter the commands you know directly in LaTeX syntax, but have all others available in a graphical toolbar and an instant preview of the result).

LyX oddities begin if you want to fine-tune a lot or use lot's of user-defined custom macros. And as with any other tool: You have to know it (the shortcuts, the workflows) and initially invest some time in configuring and customizing it to your habits. But then, in my experience, the WYSIWYM approach can be a huge time-saver and (for me) makes it easier to think about the content.

  • 6
    LyX is a blessing and a curse. If you ever have to collaborate with someone, then don't use it. I'm tired of working out and cleaning up the LyX generated code that comes my way...
    – qubyte
    Commented Nov 29, 2011 at 10:08
  • 1
    @MarkS.Everitt: ... unless your collaborators use LyX as well, of course. In that case the built-in change tracking is another valuable tool that is not so easy to get with "plain LaTeX". However: In collaborative settings, it is an all LyX or no LyX decision. (The last sentence is devoted to my ongoing LyX is not a LaTeX Editor! campaign.)
    – Daniel
    Commented Nov 29, 2011 at 11:29
  • 2
    They don't. Except that one guy and we finally bullied, (ahem) applied reasoned arguments to convince him into doing it raw a few months ago. ;)
    – qubyte
    Commented Nov 29, 2011 at 11:46

Things may change when you are writing hundreds of pages with a lot of complex code. A full compilation may be very slow: sometimes you must wait for 5 minutes. In such cases, some more advice:

  • Split long document (e.g. a book) into many small parts. Use \include and \includeonly to compile the only part you are writing. Sometimes you may even comment some parts for a faster compile.
  • Some editors (e.g. WinEdt) can "Compile Selected block", use it if you are typesetting some complex formula or table. If your editor does not suport this, you can use another empty test file to test complex equations, figures or tables quickly.
  • Don't compile too frequently when you are experienced, especially for very long documents. You can leave the unimportant errors at last.
  • Do fine tuning as late as possible. For example, if a float figure runs far away from the text, don't change the placements or move the code immediately, leave it at the final stage.

If you use Emacs, you probably already know about AucTeX, which lets you do inline previews of equations, etc., has a nice wrapper for error messages (it lets you jump to the line of the error), and gives a lot of shortcuts to insert environments. Reftex mode and cldatex minor mode might be less well known (Reftex comes with AucTeX, I think, and cdlatex is available here: http://staff.science.uva.nl/~dominik/Tools/cdlatex/) which give keyboard shortcuts for cross references, citations, and common math notation.

Getting enough experience to just be able to type the commands you want, and using a text editor that gives you a lot of keyboard shortcuts should speed things up a lot. I've moved away from defining a lot of macros; I'll define some for acronyms, but that's about it... it's just too hard to remember what I named everything when I come back to a paper after 6 months. Just typing the code in is much faster, and regexp replacement is good enough if I need to change the notation later.

  • +1: to extensive use of own macros might also be tricky in collaborations: I had the situation where we had in the end three different macros to produce a $\mathbb{R}$ or so. So better stick to orignal LaTeX and use a clever editor which gives you the code with a single key-stroke. Commented Mar 16, 2012 at 11:01

For tables, I find it useful to make the table in Excel, and convert to LaTeX - a lot of the formatting can be done in Excel (although it doesn't always translate perfectly) which is on CTAN. If you don't use Excel, there is a similar conversion utility for Open Office, or a .csv to LaTeX converter (see here for some options).

It's interesting that the answers before me have given conflicting opinions as to whether to compile frequently or not. I would suggest that you get into the habit of compiling frequently, especially when working on long formulae (which is where most of the errors seem to creep in) - if only to save time at the proof-reading stage.

TeXworks is probably all you need for an editor, although again others will have their favourites. I like the way it splits the screen so you have the editor and output displayed simultaneously, especially if you have a widescreen monitor.

I would also suggest using JabRef, which is a cross-platform reference manager. For simplicity I keep all of my references in a single file, which I store on DropBox, meaning that it's readily available whatever machine I'm working on. Importing references into JabRef is pretty simple, although its search tools are a bit hard to use. For a while I was working on a Mac, and used BibDesk on there which did pretty much the same thing and had some nice features but is MacOS only.


Some editors, like TeXStudio have wizards for this kind of situation and also provide some buttons e.g. for bold or italic fonts or have autofill options. I agree with @Mark S. Everitt that using the mouse should be avoided (for simple commands), since it only disrupts the typing flow. The faster you are able to type, the worse the mouse will impact on it. No wonder I don't know anybody who likes MS Word's Equation Editor...


The most useful tool for me is latexsuite, a vim addon. It has macros for the most important structures and lets you define templates.


I think you know, how your documents should look (if the look is always quite similar. Define all possible tables as new environments. So you just have to write for example (if you need a table with four rows):

a & b & c & d\\
e & f & g & h\\

I do it this way for minutes of meeting.

And you should use a good editor. I'm using vim with the latex-suite. In latex-suite you can define own commands and environments so you only have to write "fourcoltable" and press F5 to get an environment like shown above.

I defined some own commands wich need three arguments. I have only to write the command name and press F7 to get something like this:

\commandname{<+first argument+>}{<+second argument+>}{<+third argument+>}<++>

where <+...+> is a place holder. Placeholders are very effizient: you write your command name, press F7 and ALT+J to jump to the first placeholder; write your first argument, press ALT+J again to jump to the second placeholder. This makes you very fast, because you don't need to switch from Keyboard to mouse, place the cursor between the braces, klick, switch back to the keyboard, type your text and again from the keyboard to the mouse...

You can use this "technique" also for templates. I start vim report.tex, insert the template i need and can jump to the placeholders i always need (ie. date, participants, place, time, etc...)

With some plugins, you can write even faster. I often use the Supertab plugin. It is for Word completition. So if i have to write strange but long names (with the danger of missspelling), i only have to write the word once. Next time i should use this word i just type the first letters and then TAB. Vim will complete the word (Think about words like Acetylcholinesterase).

I can only speek for vim, i don't know emacs but i'm sure this is also possible with emacs and auctex.

It was not so hard to learn vim. But since i use it, i don't use kile, texmaker, texnicenter...

Sorry for my poor english.


I produce a lot of docs that have common chunks of content. Sales, marketing, professional services kinds of stuff.

If this happens to you, then you'll want to maintain a content library - basically a bunch of macros which contain chunks of text, tables, figures, etc. Your docs can then just call macros, and you can evolve the macros over time.

Very very helpful.

Oh yeah - and use a good text editor. I like vim. I think emacs is likely at least as awesome. Both have long learning curves and extreme payoff.

And compile often.

  • I would say that writing a paper with repeated text from (say) other papers you have written is, well, not so nice (for lack of a better term). However, in your field, it may seem appropriate.
    – Werner
    Commented Nov 30, 2011 at 3:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .