TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What is the recommended way to track down brace mismatches in LaTeX? I have a large beamer presentation, but this equally applies to any other LaTeX work I've done.

In other computer languages I've used pretty printers to highlight where things mismatch, but I can't seem to find a pretty printer for the LaTeX code itself rather than some other language inside in LaTeX.

My next thought is to start commenting out large sections of the source until the problem is pinned down.

What other strategies might be used?

share|improve this question
Some editors do delimiter highlighting. Then it's quite easy to find orphaned braces. – Count Zero Sep 13 '12 at 14:39
I tell my students to compile early and often - any program in any language, including TeX. Then you know the error is in the small piece you just modified. I always regret it when I don't take my own advice. – Ethan Bolker Sep 13 '12 at 14:39
@CountZero Agreed unles it's a big file that you've been editing in a gui and the mouse decides to move without your input... you hit space and you've accidentally deleted a brace and the screen jumps - yes I know it's not ideal... but hey I blame the driver! Oh dear! – Sean Sep 13 '12 at 14:45
The log file gives a line number that may help. Another strategy is to move \end{document} earlier in the file to see when the error disappears. Try using this in a binary search strategy. – Andrew Swann Sep 13 '12 at 15:52
As always: use emacs (and AUCTeX). Simple problems are easily found through syntax highlighting or M-x check-parens. For more complex needs there's things like rainbow-delimiters.el. – jon Sep 13 '12 at 20:21
up vote 10 down vote accepted

The log file usually gives some help. For example if you start an environment without ending it then you get

! LaTeX Error: \begin{quote} on input line 16 ended by \end{document}.

which tells you where group started, if it doesn't tell you where it should have finished.

If you have mis-matched { } pairs it depends whether they are being used for grouping or argument delimiting.

In the former case you get

(\end occurred inside a group at level 1)

which tells you something is bad and if at the start of the document you put


you get in addition

### simple group (level 1) entered at line 16 ({)
### bottom level

which tells you where the { was.

If it is argument matching ie you have \textbf{ with no } then you get:

Runaway argument?
{ \par aa bb xx cc \par \par \par \par 4 $\hat {\hat {\mathcal {A}}} \ETC.
! File ended while scanning use of \textbf .

which gives you some context, but not a line number, although if you have the tracinggroups set as above it is easy to guess as you are told the last group that was entered or left before the error, in this case the log shows

{leaving math shift group (level 1) entered at line 14}
Runaway argument?

so it isn't too hard to spot the error on line 16 as line 14 was OK and line 15 (in this case) was empty.

share|improve this answer
Well, many LaTeX2e commands are defined in terms of @-ful macros which actually grab the argument. That means that the error messages are not nearly as helpful as you make them seem. Joseph's worked hard to get better error messages in xparse (the function grabbing the 3rd argument of an xparse-defined command \foo is named \foo (arg 3)). – Bruno Le Floch Sep 13 '12 at 16:52
@BrunoLeFloch well yes the command names shown can be fairly arbitrary depending on the expansion path but you can usually figure out the line number which was what I wanted to highlight. – David Carlisle Sep 13 '12 at 19:06
@BrunoLeFloch Actually, it's mainly '\foo ' (with a space in), although some of the expandable ones are a bit different. Principal is correct though: give an error that makes some sense to the user :-) – Joseph Wright Sep 13 '12 at 20:21

the answers so far address problems in a single-file job. things get a bit more complicated if there are multiple files processed with \include or \input. when that happens, and there is a report that (\end occurred inside a group at level 1), if a line number is given, you don't know what file that line is in.

i use emacs, and take advantage of the fact that one can ask how-many for a file. first, get a list of the files being included. then, go into them one by one. ask how many { and then how-many }. if the counts don't match, you've potentially found the problem file. if you're lucky, your warning included a line number, so use it. if not, go halfway down the file, and (preferably at a "clean" location like a paragraph or section break) repeat the how-many mantra. this is usually enough to localize the problem well enough to inspect the text by eye.

alternatively, use the approach of inserting \end{document} at various points in the problem file until the warning goes away, then eyeball the intervening text for the problem.

yet another approach is to comment out \include and \input statements, starting with the last one; when the warning disappears, you've found the problem file, and can then use one of the other tactics inside that file.

(i used the 'how-many` approach on a 15-chapter book a few days ago, and found the problem in less than 10 minutes; it was in chapter 3, so i was lucky.)

share|improve this answer
+1 for how-many. Another thing in an unending list of things emacs does that I didn't know about. But regarding the issue of \included or \inputted files, I thought that's what the -file-line-error option was supposed to help with..? – jon Sep 20 '12 at 1:50
@jon -- well, i didn't know about the file-line-error option, so it seems i have some studying up to do too. thanks. – barbara beeton Sep 21 '12 at 19:43
Vim version of the Emacs how-many WORD is :s/WORD//n. The Vim plugins matchit or Automatic TeX Plugin will highlight matching \begin{} and \end{} statements. – Sameer Feb 14 '15 at 0:20

I like going through the output, and try to detect where it went wrong. For example if a section following a in line equation is all formatted like an equation, then you've missed a $

But if the delimiter I'm hunting is a brace, as you're asking about, I use either the build in high light tool in TeXmaker or TeXnicCenter on windows or TexMaker on linux. If I have selected a brace it will light up the corresponding brace, that way I'll have to go through the entire document. The portion of the doc to be hunted in can be trimmed by commenting sections out, like you said, starting from the top of the doc (in my experience, the missing brace is the closing brace and almost never the starting brace)

I'm sorry but some great tool for this would be much appreciated.

share|improve this answer

LEd (http://www.latexeditor.org/) colours braces so that you can immediately see which ones match:

enter image description here

I find that detecting problems using this is much faster than e.g. using an editor that highlights the brace matching the one under the cursor.

Edit: turns out this is called 'rainbow parens'; cf. e.g.

http://www.emacswiki.org/emacs/RainbowDelimiters http://www.vim.org/scripts/script.php?script_id=3772

share|improve this answer
I have found LEd to be really unstable. Without any continuing development (current download is a beta dated 2009), I found that it was prone to crashing on Win7, and it would often lose lots of work, or files became corrupted. – J M Sep 13 '12 at 16:38
@Mohan Looks like it's Windows only and I'm on Linux (oops should have said!) – Sean Sep 13 '12 at 16:49
The feature is definitely supported by other editors (see my edit). . I wish I could figure out what program this was taken from... s3.amazonaws.com/imgly_production/3303667/large.png – Mohan Sep 13 '12 at 18:59

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.