Georg Baum schreef op 10-10-2013 23:41:
OK, I believe I understand what happens, but I can't test, since I do not
see the \newcommand differences: The MacroData which is constructed from a
DocIterator is a lazy version, which does not have data initially, but
queries it when needed. This is not bad per se, but implemented in a hacky
way through all these mutable members. Unfortunately this implementation is
incomplete, since an updateData() is missing in redefinition() and type().
Therefore, it could happen that a redefinition() call in the command line
export does not return the correct data, but the same call in the GUI export
returns the correct data, since any other member is queried by the GUI. The
updateData() calls in requires() are not needed, since this member is not
filled in updateData().
Does this patch fix the problem for you?
First of all it is a misunderstanding that the bug manifests itself as a
difference between GUI and non-GUI export: "It's just another joy of
multithreading".
As I wrote somewhere else, it was a problem of
MathMacroTemplate::metrics to modify the redefinition_ mutable variable.
While exporting the document, and with the macros in view, the metrics
computations altered this variable affecting the output.
I now removed this offending code, but I have no clue why it was done in
metrics anyway as the redefinition_ variable is only used in the write
function. Buffer::Impl::updateMacros makes sure that the redefinition_
variable is set correctly. Maybe we missed some cases before and doing
this in the metrics was a cheap trick (this code was committed in an
almost 3000 lines commit: not helpful).
I'll send the patch shortly after.
Vincent
