Le 01/04/2015 21:49, Georg Baum a écrit :
Jean-Marc Lasgouttes wrote:
Le 31/03/2015 21:38, Georg Baum a écrit :
BTW updateMacros is quite heavy on big documents (#5973) and I have
medium-term plans for making the update lazy. This may become
unnecessary if you can do another kind of miracle. M
On 04/05/2015 11:01 AM, Georg Baum wrote:
Georg Baum wrote:
All ArgumentProxy instances are contained in MathMacro::expanded_, which
means that there is always a unique parent-child like relationship between
MathMacro and ArgumentProxy. Therefore, a single place exists where
ArgumentProxy::math
Georg Baum wrote:
> All ArgumentProxy instances are contained in MathMacro::expanded_, which
> means that there is always a unique parent-child like relationship between
> MathMacro and ArgumentProxy. Therefore, a single place exists where
> ArgumentProxy::mathMacro_ can become invalid, and where
Jean-Marc Lasgouttes wrote:
> Le 31/03/2015 21:38, Georg Baum a écrit :
>>> BTW updateMacros is quite heavy on big documents (#5973) and I have
>>> medium-term plans for making the update lazy. This may become
>>> unnecessary if you can do another kind of miracle. My plan is to use
>>> recordUndo
Le 31/03/2015 21:38, Georg Baum a écrit :
BTW updateMacros is quite heavy on big documents (#5973) and I have
medium-term plans for making the update lazy. This may become
unnecessary if you can do another kind of miracle. My plan is to use
recordUndo to increment a version_id for the buffer. The
Jean-Marc Lasgouttes wrote:
> Could you tell us a little bit about ArgumentProxy and what is is good
> for?
It is used for macros with arguments. Each argument of a math macro is one
cell of the macro. An ArgumentProxy is the expanded representation of such a
cell. It has basically no own data
Le 30/03/2015 22:42, Georg Baum a écrit :
Meanwhile I do have a better understanding of the math macros and found
another solution which I think is much better. First, it is really very
difficult to get rid of ArgumentProxy::mathMacro_. So, I stopped trying to
get rid of it but rather tried to fi
Richard Heck wrote:
> On 03/22/2015 09:14 AM, Georg Baum wrote:
>> Jean-Marc Lasgouttes wrote:
>>
>>> Le 20/03/15 21:53, Georg Baum a écrit :
The real cause for the bug is that ArgumentProxy::mathMacro_ is a
reference to an object which is stored in a MathData, which is a
std::vecto
On 03/22/2015 09:14 AM, Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Le 20/03/15 21:53, Georg Baum a écrit :
The real cause for the bug is that ArgumentProxy::mathMacro_ is a
reference to an object which is stored in a MathData, which is a
std::vector storing MathAtoms by value (not pointers)
Jean-Marc Lasgouttes wrote:
> Le 20/03/15 21:53, Georg Baum a écrit :
>> The real cause for the bug is that ArgumentProxy::mathMacro_ is a
>> reference to an object which is stored in a MathData, which is a
>> std::vector storing MathAtoms by value (not pointers). Therefore, each
>> time when the
Le 20/03/15 21:53, Georg Baum a écrit :
The real cause for the bug is that ArgumentProxy::mathMacro_ is a reference
to an object which is stored in a MathData, which is a std::vector storing
MathAtoms by value (not pointers). Therefore, each time when the MathData
object which contains a math mac
Georg Baum wrote:
> This problem would be easily avoided if one would iterate backwards
> through the macro insets (a macro can never reference another one which
> follows later), but unfortunately I failed to implement that, since I do
> not understand the DocIterator stuff well enough. I tried s
12 matches
Mail list logo
