# Debugging help, something about an end note

I am getting this error

[275

]
! Argument of \@doanenote has an extra }.
<inserted text>
\par
l.726 {citation}

?


This raises a number of questions:

• What is causing this?
• What does the l.726 mean? I have assocaited this in the past with the line number, but I don't have any files with this many lines.
• How can I tell what file this problem occurs in?
• I don't have any occurrence of doanenote in my text ... how does one in general learn to associate what the error message says with something I might have done in the text.
• I have checked my files and they have equal numbers of open and close braces, so whatever it is not simply that I have an extra end brace. In general, when it says you have an extra end brace, what do you look for?
• Is there a good reference on how to decrypt these rather opaque error messages?
• Is there any way to encourage better compiler error output. I know it is an open source effort, but is there a place to help, or a group concerned about this?

Any help would be appreciated.

I believe the 275 is in reference to the page of the output document, because there are other comments mentioning page 275. That page 275 is the last page of the notes section --- and the notes sections ends prematurely (probably less than half the notes appearing). I am examining the endnote commands around that point in the book.

Thanks everyone, I found the problem to be a couple nested of footnote statements inside of a footnote (I had been using footnotes as reminders to myself to put in citations, and then I converted a block of text to a real footnote failed to notice the embedding.)

Here is the MWE:

entire machine.  Analysis\footnote{Analysis is most often characterized
as breaking something down into its components to gain a better understanding
of it.  The Oxford Dictionary states that analysis is the process of separating
something into its constituent elements. Often contrasted with
synthesis.''\footnote{citation} The Stanford Encyclopedia of Philosophy
states that Analysis has always been at the heart of philosophical method,
but it has been understood and practiced in many different ways. Perhaps,
in its broadest sense, it might be defined as a process of isolating or working
back to what is more fundamental by means of which something, initially taken
as given, can be explained or reconstructed.''\footnote{citation}  Whether
used in a decompositional way, or a regressive say, analysis is a technique
that predates Aristotle and Socrates and forms the logical basis of mathematics
and many sciences.} does not work on complex systems;


I can honestly say, that the error message is inadequate. A simple accurate "filename and line number" would be 1000% more helpful. The line number reported appears to be a cumulative number of all the files added together --- not a line of a particular file.

• This seems to be part of the endnote.sty package. But we can't help you without an MWE. There could be so many thing causing this error. Even if the number of curly braces is correct. Please reduce your code to this very error and you will find the problem. – LaRiFaRi Oct 21 '14 at 20:55
• Regarding the interpretation of opaque error messages: tex.stackexchange.com/q/113745 – LaRiFaRi Oct 21 '14 at 20:59
• the l.726 is almost certainly the line in the endnotes file, which has been compiled during the tex processing of the main file. i don't remember what that file is named, but if you look to see what files are in your working directory, it should be obvious. – barbara beeton Oct 21 '14 at 21:10
• Just FYI none of the input files, nor any of the temporary files, are 726 lines long. The longest is 710 lines. Looks like I will be doing a manual binary search by eliminating blocks of input until I isolate the problem. – AgilePro Oct 21 '14 at 21:31

I am trying to answer all your question but the debugging work will stay with you:

• The error is caused by something in combination with the package endnotes. When having a look to its source, you can find the command \@doanenote. There are many commands called in a document, which you do not call by your self. So searching for it in your source will not result in any clue. The error is saying that it encounters problems in finding the beginning of some group or environment. Could be anything. At the point where the compiler stops, it sees one } too much. The reason could be that there are too many brackets, or hat some other delimiter such as \$ or any environment or or or is blocking.

• l.something is a line number. But it could be in some reference or bib file. Hard to tell. If the error appears inside of an environment, the compiler sometimes can't find the real line number of your source code but takes the end of the environment for reference.

• You have to minimize your code; chapter by chapter, section by section... kick out all packages, all commands and definitions, until you see the one line in which the error appears. An MWE is the only answer to this point.

• just google the command and you will get a hit in most cases. Like I did. Then you know at least, what package the command is used in.

• Of course I check for extra braces first. But this is just the problem for some of the cases you might encounter. An MWE will show you whether that’s the cause or not. Happens all the time, btw., and sometimes you search eternally without seeing it.

• Kind of a reference for such warnings can be found here. And of course in each documentation of the packages you or your documentclass is unsing.

• If you want to contribute something, great! I would get contact with the TUG for the starting. Or you do a feature request to the maintainer of endnotes when you found the error. But this is most certainly a TeX-compiler problem.

• This is very helpful. I will start a binary search for the line of code causing the problem. – AgilePro Oct 21 '14 at 21:34
• this may not be a compiler problem. for example, there is a situation in index processing where "delayed" input is quite fatal: if a comment is inserted within the scope of an \index{... % ...} entry, it is not treated as a comment in the main processing run; instead, the literal content of the \index argument is pushed off into the .idx file, and not affected by the makeindex run, so in the middle of the .ind file there is an unwanted %. if this happens to be between braces or in math in the index entry, the job explodes with an inscrutable error. so i suspect a "derived" file. – barbara beeton Oct 22 '14 at 12:25