# How to quickly troubleshoot errors caused by missing closing brackets?

Perhaps the most common mistake I make is to forget to place a closing bracket, i.e. }, or closing command, e.g. \end{description}. When compiling, such mistakes usually do not say, "\begin{description} is missing a closing command.", rather, they say something like, "\end{document} appeared unexpectedly."

• In a large, complicated document, it can be difficult to find the source of such errors.
• When the errors appear inside an \input file, these are often more difficult to find.
• These are further made difficult when some macros require additional brackets, e.g. \begin{tabular}{lll}.

Are there any techniques or strategies one can apply to quickly locate the items which are missing closing items, in a document?

• emacs has M-x check-parens, which looks for unbalanced braces, parentheses, and brackets. That's what I use. Back in the day, I also made use of bibclean, I think, for .bib files. But I don't have it installed any more.
– jon
Apr 29 '12 at 23:23
• Compile frequently as you write. Then you'll know the missing item is something you typed recently. Apr 29 '12 at 23:37
• I know it's a bit ideal, and can be difficult to keep up, but try always to insert balanced structures. Thus when you insert a \begin{}, insert the corresponding \end{} at the same time, and always enter "{}" then back up and fill in. Of course, autocomplete will help a lot, too. Apr 29 '12 at 23:48
• @Brent.Longborough I have an emacs macro that inserts the \begin{foo}...\end{foo} pair and leaves the cursor between them. Apr 30 '12 at 0:02
• My comments on this are documented at Help me to write Long LaTeX equations fast with colours and possibly with other aids, and I apply similar techniques for environments in that I add the end{environment} at the time I add \begin{environment}. Apr 30 '12 at 1:21

## 5 Answers

If you are using e-TeX (which you probably are), you can make TeX record grouping levels and strangenesses in the log file by

\tracinggroups=1
\tracingnesting=2


This can probably help to find the cause of an error if it is due to a grouping problem.

In your own code, it's probably best to give a short log message at the start of a group level so you can immediately identify in the log what groups are started and closed where.

Furthermore, you can show the current group nesting at any time in your code with

\showgroups


May I suggest you to use the syntonly package. It must be declared in the document header,

\usepackage{syntonly}


then, right after it you write

\syntaxonly


what it does, it checks only the syntax without compiling the document. It does not provide further help in spotting the errors, but at least you can avoid to compile the document unsuccessfully. Once the syntax is correct, just comment it.

%\syntaxonly


It's not nice, but for me debugging these types of latex errors, if you have a large document and really no idea where the wrong bracket structure might be, works best with the old "binary search".

Just comment out half of the document, compile, if it works, proceed with the commented part, otherwise with the uncommented part.

(If you \input files, proceed accordingly with the nested code.)

Seriously, call it stupid, but most of the time it's quickest to do exactly this, even though there are - theoretically - situations where you produce new errors by the commenting. Usually it's easy to see how to comment so it doesn't happen.

Of course, nicely to be combined with gcedo's answer.

While I use TexMaker, I keep TeXnicCenter installed (but not the windows default) for this purpose. http://www.texniccenter.org/resources/downloads/29

Open TeXnicCenter, load the offending file. Put the curser in the middle of the suspected problem area. Press Ctrl-m and it will highlight the contents of the inclosed brackets. Press again and it increased scope. This usually provides me a fast identification of the problem. Especially when debugging student problems.

This only pertains to mismatched brackets in inline equations, but may be useful still.

After spending way too long looking for an error in my inline equations, I made the following Python script which lets you paste in your suspect tex, and scans each equation for imbalanced brackets and other sneaky syntax errors:

import re

def find_invalid_equations_in_tex(tex):

lines = [line for line in tex.split('\n') if len(line.strip(' '))>0]

for line in lines:
print('Running Line starting with: "{}..."'.format(line[:16]))
result = re.findall(pattern='\$.*?\$', string=tex)
for eqn in result:
n_opens = len(re.findall('\{', eqn))
n_closes = len(re.findall('\}', eqn))

prefix = 'Error on Line starting with: "{}..."\n  '.format(line[:16])
assert n_opens==n_closes, prefix+"Equation\n  {}\n.. has {} {{'s than }}'s".format(eqn, 'more' if n_opens>n_closes else 'fewer')

double_prefixes = re.findall(pattern='\\\\[a-zA-Z]+\s*\\\\[a-zA-Z]+\{.*\}', string=eqn)
assert len(double_prefixes) == 0, prefix+"Detected invalid  'double-prefix' syntax.  Change from: '\\aaa\\bbb{{ccc}}' to '\\aaa{{\\bbb{{ccc}}}}':\n  Equation: {}".format('\n  '.join(double_prefixes))

print('.. {} is clear'.format(eqn))
print('  No brace mismatches found in {} equations.'.format(len(result)))
print('No errs found in {} lines'.format(len(lines)))

def get_multiline_input(prompt):

print(prompt+".  Press CTRL-D (or Command-D on Mac) once done.")
contents = []
while True:
try:
line = input()
except EOFError:
break
contents.append(line)
return '\n'.join(contents)

tex = get_multiline_input('Paste your suspect tex here >> ')
find_invalid_equations_in_tex(tex)

• In a TeX group, maybe a Lua script would be another nice tool. Nice script, tho 💖
– user193767
Jun 27 '20 at 9:46
• idk why, but nothing happend when I pressed CTRL+D :( Oct 25 '20 at 20:27