..and I don't mean finding out why it doesn't compile, I mean serious debugging: breakpoints, figuring out value of variables at a given moment during run/compile, stepping, examining a stack (is there one?), etc. All the things that we take for granted when debugging a "real" programming language. Since TeX is "turing-complete", I would like to be able to really see what is going on internally.
I'm guessing that a GUI interface for the debugger would be too much to ask, but if it exists, I'd love to hear about it.
Best Answer
The trace package will load everything that TeX is doing during a particular piece of the run. The problem with that is that you can get a lot of information very rapidly. Selectively using trace can give a lot of insight into problems. At a lower level, there are various tracing settings that TeX provides (and which the trace package makes use of). It's possible to set just some of these values to get TeX to log certain parts of what it is doing, for example just assignments. Normally, the trace package is enough.
For examining variables, the
\wlogmacro is the easiest way, although you can simply put\showor\showthein the right places if it's a single thing you want to know.One thing I do a lot (especially with infinite loops) is simply insert an undefined control sequence into the code (I use
\MARK). This will stop TeX with an error, and I can therefore see where I'm up to. Not elegant, but it works for me.The way TeX writes to the log can mean that you get an infinite loop without all of the data you want being added to the log. Strategic placement of
\@@end(the TeX primitive\endrenamed by LaTeX) can be used in these circumstances to force the run to end.I'm not sure how a graphical debugger would work, but then I only really program in TeX, so I'm used to the approach I've outlined. I've never come across one.