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

I am too slow LaTeX-typist, for example with the equations below I cannot find where I am missing some bracket. Could someone offer me some computational method? I use Vim but I am happy with any method you have in hand.

$\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}$


Perhaps related

-
Inside the math mode you every space is ignored. So you can structure your equations by space in relation to your braces. – Marco Daniel Feb 11 '12 at 15:38
I'm an Emacs/AUCTeX user instead of Vim, but I guess Vim, too, has some form of parentheses match highlighting, see also tex.stackexchange.com/questions/6470. I myself now comfortable use the check-parens script from my answer as "compiler": it outputs line:pos numbers of mismatching parentheses that I can then directly jump to. – eldering Feb 11 '12 at 15:54
the last \right} is wrong is it a typo here or also in your code? – Herbert Feb 11 '12 at 15:59
You should not use ln but a log-like function. If the function you need is not already defined in LaTeX, you can define it with \mathop. BTW, I use TeXworks and it shows me matching ()'s and similar symbols (almost always). – ASdeL Feb 11 '12 at 16:16
If you're using vim, you may rest your text cursor on any delimiter (brace, parenthesis, square bracket) and pressing the % key, vim will move to text cursor to the corresponding matching delimiter. – Marc van Dongen Feb 11 '12 at 17:18

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

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
-
@hhh you're very welcome :) happy vim-TeXing! – cmhughes Feb 11 '12 at 18:04
@hhh Alas, the images you see above were made by taking screenshots & clipping- very inefficient! You might like the vimperator addon for Firefox – cmhughes Feb 12 '12 at 17:36
@hhh I'd use [[ for the brackets. I prefer not to use \ll and \lv- I use my own compilation commands which link to my own scripts instead- I can post them somewhere if you're interested. \ref{} F9 opens a list of \label tags for me – cmhughes Mar 21 '12 at 15:53
@hhh I pasted them in paste bin http://pastebin.com/u/cmhughes, the files from today (March 21, 2012) are the appropriate ones- details of where to put them are in the title of each file – cmhughes Mar 21 '12 at 16:29
Related q here. – hhh Mar 24 '12 at 20:57

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.

-
...slow latex-typist, I can write 70-80wpm -- I think this is above average 50 or something like that... but there is always room for improvement such as in fluency, ordering and case :P I have seen some programmers to have different rainbow colors for brackets...I feel something like that would be convenient... – hhh Feb 11 '12 at 16:57
...btw I use NerdCommenter in Vim while programming, there must be something like that also for LaTeX -- such small things that can enermously speed up writing and readability. When I did lisp, I used some rainbow colors -- searching. I think I am slow LaTeX -typist because I cannot see the fine-print, I find it extremely hard to see things, pattern matching is slow without some aid such as colors or structures. – hhh Feb 11 '12 at 17:05

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}} \\
\end{align*}
\end{document}

-
Related Question: Help me to debug long LaTex equations with errors. – Peter Grill Oct 5 '12 at 0:42

I have a weird suggestion (depending on where you live in the world): Change your keyboard layout. In the default Finnish (/Swedish) qwerty on OS X, for example, I'd need to press Shift+Alt+9 to get a }.

Which isn't exactly fun with TeX.

So I made a TeX keyboard layout (which, btw, I use all the time, not just with TeX) with Ukelele where I mapped a key which I surprisingly rarely needed, å, to { and its majuscule (shift modifier) to }`.

Naturally this sped up my TeX typing.

-
Related question: tex.stackexchange.com/q/1979/86 – Loop Space Mar 29 '12 at 12:34
Did similar enhance many years ago: changed to OSX -mappings, then to US International and then International Dvorak with Deadkeys -- changed-and-used many different OSs during the cycles. Now it is time to do next improvement. – hhh Mar 29 '12 at 13:46

I used Kile to take notes directly in LaTeX during a class in an astrophysics at the university. sometimes I missed something and had to write it down by hand but it worked pretty well.

I used the Kile shortcuts to type formulas very fast, it requires a little time to get used to use them, but then one can learn to be really fast. It has only 9 or 10 shortcuts but in the same work most math uses the same symbols again and again.

-