# Help me to write Long LaTeX equations fast with colours and possibly with other aids

I would highly recommend the vim latex-suite, which you can get either from

http://vim-latex.sourceforge.net/index.php?subject=manual&title=Manu

or (on an Ubuntu machine) using

sudo apt-get install vim-latexsuite


It provides many shortcuts. If I were going to type your first summation

\sum_{n=2}^{\infty}\left( \left(2^{n} \right) 2^{n/k} ln(2^{n})\right)^{-k}


I would use the following keystrokes

• \sum__ (two underscores)

• n=2 CTRL+J

• ((

• ((

• 2^{}n CTRL+J CTRL+J

• 2^^n/k CTRL+J

• \ln()

• 2^^n CTRL+J CTRL+J CTRL+J

• ^^-k CTRL+J

When you press CTRL J, the cursor takes you to the position of the next <++>, deletes the <++>, and leaves you in insert mode, ready to type. Once you get used to it, it is a very useful device and huge time saver.

Some other miscellaneous shortcuts that I have found very useful (and there's a lot more that I'm sure I haven't explored yet)

• ()
• {}
• enumerate F5
• itemize F5
• \ref{} F9
• /
• myenvironmentname F5

A quite long comment...

I don't think your question is specific to Vim or any other editor. Whether you are given a code completion, auto-environment closing tool or not it is quite important to reduce the mental load while writing your code. A short-term loss can be a long-term benefit if you can spend extra seconds to write-up with a better indentation. I am definitely not a programmer but I do LaTeX coding a lot for articles etc. and even worse I collaborate with many other individuals using the same code.

You also mention that you are a slow-typist which makes this even easier to implement since you won't be speeding up like a die-hard programmer. You can easily adopt a few coding practices and use the TAB key extensively. Here is a personal example

$\sum_{n=2}^{\infty} \left( \left( 2^{n} \right) 2^{n/k} ln(2^{n}) \right)^{-k} = \sum_{n=2}^{\infty} { e^{-k \left( n( 1+\frac{1}{k} ) ln(2)+ln(n)+ln(ln(2) ) \right }$


I have exaggerated a little bit since normally you would keep things a little more compact depending on your own eye-sight. I guess the rule of thumb is to let your code lines go as much as you can subitize.

As we can easily see, you are missing one closing curly bracket and a parenthesis or the \right is after the closing parenthesis. This is far from optimal but at least gives an idea of coding for your own benefit.

A LaTeX specific detail would be the % character at the end of some lines where the command used is sensitive to whitespaces and newlines. That is something I also tend to forget but I'm getting more experience with what requires and what not. Nevertheless it pays off since my debugging time is reduced substantially. ( Behind closed doors I put it at the end of each line anyway.)

You can start by searching the horrible keywords Best coding practices etc. and reading from the real programmers.

When starting a rather long document (book, thesis, etc), almost everyone begins with defining the various chapters, then the various sections and then start a particular section by outlining the points they want to cover in there and then go and fill in the details. That is, they work top down rather than bottom up, by placing each section (or at least every chapter) in a separate file.

But when it comes to math, a common tendency is to type them as is from the beginning to the ending which I believe results is quite a bit of grief as formulas start to get beyond a basic polynomial.

So, when it comes to math I believe a similar approach is necessary.

So, besides the practice of code indenting (ie, having the top down hierarchy easily visible), I have gotten into the habit of closing anything I begin at the same time as opening it. So, with \frac I immediately go and add {}{} and then go back and fill in what goes inside. Same with left( right) and then go back and fill in what is inside. If the fraction happened to be rather complicated I start with:

\frac{}
{}


or for even more complicated ones that I know will take up many lines:

\frac{
}
{
}


Similarly for any environments I do

\begin{}
\end{}


and then go and fill in what is in between.

Finding the appropriate missing brace can sometime be rather difficult and this practice alone has cut down the amount of errors I make significantly. However if I still have an error and can't easily spot it due to the indentation I double click on the opening (or closing brace) and see where the matching one is. This should work with most IDEs - I know it does with TeXShop and TeXWorks.

A difficulty in using this matching technique comes when one has \left( \right. as the IDEs can not find the matching component and things go awry. So in this case you could either temporarily change the end parenthesis to right) and remember to go back and fix it, or use a macro that builds this construct so that the IDE only has a {} to deal with. For example below I use \BracRLeft{} and \BracRRight{} to obtain:

The IDE only had to deal with matching brace groups in the actual code.

\documentclass{article}
\usepackage{amsmath}

\makeatletter
\newcommand{\@Brac}[3]{\left#1 #2 \right#3}% General \left \right construct
%                                                #1 = bracket type on left
%                                                #2 = argument in brackets
%                                                #3 = bracket type on right
%
\newcommand{\BracR}[1]{\@Brac{(}{#1}{)}}%        \left( \right)
\newcommand{\BracRLeft}[1]{\@Brac{(}{#1}{.}}%    \left( \right.
\newcommand{\BracRRight}[1]{\@Brac{.}{#1}{)}}%   \left. \right)
\makeatother

\begin{document}
\begin{align*}
f(x) &=      \BracRLeft{\frac{1}{2}} \\
`