This is an old revision of the document!

A PCRE internal error occured. This might be caused by a faulty plugin

====== Things I do in LaTeX which may need justifying to co-authors ====== Quick things: * In a hand-marked-up PDF, a tilde at the end of a line indicates a "tie", to keep characters bound to the word that precedes them, see * It is useful for version control to issue a soft newline after each full stop. ====== All one file ====== Lots of people feel more organized if they have an outer ''paper.tex'' which ''\include''s ''intro.tex'', ''litreview.tex'' etc. I used to do that too. Now I find that one large file is better. Here's why - You obviously have your document in some version control system. If you move a block of text from one file to another, none of the VCSs know how to deal with that in the presence of conflicts. In LaTeX it's very common to have to move a block of text, because one needs to move figures. Of course you don't do that till the very end, right? Yes, that's exactly when you don't want a mass of conflicts, and yet it's exactly the point when everyone is frantically trying to fix their section. - If you want to globally search and replace it's much easier to do so in a single file. Yes, of course you should have had the notation right before you started. But you didn't. - If you really think compilation is too slow without ''\includeonly'', try ''texify --quiet'' first. - Now, of course it's not a good idea to copy/paste large figures into the main file, but one small tweak makes it much easier to find figure labels etc. Put the graphical content into figs/mybigfig.tex, but put caption and label in the main file: <code> \begin{figure} \input{figs/mybigfig.tex} \caption{lots of lovely plots, all lovingly tikzed (pron TIK-zeed)} \label{fig:tikz-virtuosity} \end{figure}</code> ====== Inline macro definitions ====== Lots of people feel more organized if they have all their macro definitions at the top of the file (or in ''macros.tex''). I agree, for generic macros. However, for symbols, I prefer to define them at the point in the text when they are first introduced. This means that you get an error if you try to refer to \params before they're defined. Example: <code> \section{Methods} In this section we blather on for a while about what we're going to do, and then in paragraph two, we'll actually tell you. If I accidentally try to talk about $\img$ here, I'll get an error. \def\img{\mathcal{I}} \def\samp{\mathbf{g}} \def\nsamp{n} We consider an image $\img$ as a list of samples $\{\samp_i\}_{i=1}^\nsamp$. </code> ====== Misc stuff to paste in the top ====== <code> % -*- compile-command: "texify --pdf -V --quiet main.tex" -*- % Silence includegraphics \setkeys{Gin}{quiet=true} \usepackage{xspace} \newcommand{\etal}{\emph{et al.}\xspace} </code> And see <code> % Twocolumn marginpar, e.g. for CVPR/ICCV \newcommand\authornote[2]{\textcolor{blue}{\hspace{-1pt}\rule{2pt}{2ex}\hspace{-1pt}}% \marginpar[~\hspace{-12mm}\parbox{16mm}{\tiny \textcolor{blue}{#1:#2}}]% {~\hspace{-4mm}~\parbox[t]{20mm}{\tiny \textcolor{blue}{#1: #2}}}} </code>