Jean-Marc Lasgouttes wrote:
> > It's much easier to debug if it's in trunk.
>
> Sure.
OK. The bar is open.
Jürgen
Jürgen Spitzmüller writes:
> Jean-Marc Lasgouttes wrote:
>> I agree with that. We have to identify central places where this could
>> be done.
>
> OK, I propose I commit what I have and add FIXMEs to the new updateLabels and
> setBuffer calls.
>
> It's much easier to debug if it's in trunk.
Sur
Jean-Marc Lasgouttes wrote:
> I agree with that. We have to identify central places where this could
> be done.
OK, I propose I commit what I have and add FIXMEs to the new updateLabels and
setBuffer calls.
It's much easier to debug if it's in trunk.
Jürgen
"Vincent van Ravesteijn - TNW" writes:
>
>>> updateLabels() in InsetMathNest's LFUN_CUT dispatch seems to fix the
>>> crash. However, the pasted ref is not updated...
>>
>>OK, now InsetMathGrid joins the party. This, additional to the above, fixes
>>the issue for me.
>
> On a sidenote, I'm g
Enrico Forestieri wrote:
> I would place "cur.inset().setBuffer(*cur.buffer());" just before
> "cur.buffer()->updateLabels();" in order to also account for the
> else case (multiple cells). Why not simply use setBuffer(*buffer_) ?
OK to both.
Jürgen
On Thu, Jan 28, 2010 at 04:17:43PM +0100, Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
> > updateLabels() in InsetMathNest's LFUN_CUT dispatch seems to fix the
> > crash. However, the pasted ref is not updated...
>
> OK, now InsetMathGrid joins the party. This, additional to the above,
Vincent van Ravesteijn - TNW wrote:
> On a sidenote, I'm getting increasingly worried about increasing number of
> updateLabels() and setBuffer() calls scattered all over the place.
Me, too. But I fear this is the cost of having mathed integrated with the
updateLabel mechanism.
Jürgen
>> updateLabels() in InsetMathNest's LFUN_CUT dispatch seems to fix the
>> crash. However, the pasted ref is not updated...
>
>OK, now InsetMathGrid joins the party. This, additional to the above, fixes
>the issue for me.
>
On a sidenote, I'm getting increasingly worried about increasing numb
Enrico Forestieri wrote:
> > updateLabels() in InsetMathNest's LFUN_CUT dispatch seems to fix the
> > crash.
>
> I think that it is better to place updateLabels() in InsetMathGrid's
> LFUN_PASTE.
We need both. If an InsetRef is just cut, we need to update the reference
cache as well, or it has
On Thu, Jan 28, 2010 at 03:49:41PM +0100, Jürgen Spitzmüller wrote:
> updateLabels() in InsetMathNest's LFUN_CUT dispatch seems to fix the crash.
I think that it is better to place updateLabels() in InsetMathGrid's
LFUN_PASTE.
> However, the pasted ref is not updated...
Yes, this is more trick
Jürgen Spitzmüller wrote:
> updateLabels() in InsetMathNest's LFUN_CUT dispatch seems to fix the
> crash. However, the pasted ref is not updated...
OK, now InsetMathGrid joins the party. This, additional to the above, fixes
the issue for me.
Jürgen
Index: src/mathed/InsetMathGrid.cpp
=
Enrico Forestieri wrote:
> Yes, that did the trick. However, now I have the next one :(
Nice game...
> Cut a ref inset which is outside a \text inset and then paste it
> again at the same position. Now modify the label and enjoy YA crash...
updateLabels() in InsetMathNest's LFUN_CUT dispatch see
Abdelrazak Younes wrote:
> This avoids the recreation of the InsetMathRef. So instead of creating
> another instance and copying its content you would just call
> InsetMathRef::init().
But I have to modify its content (i.e., cell(0)).
Jürgen
On Thu, Jan 28, 2010 at 03:11:31PM +0100, Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
> > Yes, I noticed. These new refs do not have a valid buffer, so
> > updateLabels() stops. Either we need Abdel's init() idea or yet another
> > setBuffer call somewhere.
>
> A setBuffer call in Cur
On 01/28/2010 03:14 PM, Jürgen Spitzmüller wrote:
OK, thanks, but I still do not understand how this will help me. Sorry for
being so dull.
This avoids the recreation of the InsetMathRef. So instead of creating
another instance and copying its content you would just call
InsetMathRef::ini
OK, thanks, but I still do not understand how this will help me. Sorry for
being so dull.
Jürgen
Abdelrazak Younes wrote:
> Index: src/mathed/CommandInset.h
> ===
> --- src/mathed/CommandInset.h(revision 33247)
> +++ src/mathed/
Jürgen Spitzmüller wrote:
> Yes, I noticed. These new refs do not have a valid buffer, so
> updateLabels() stops. Either we need Abdel's init() idea or yet another
> setBuffer call somewhere.
A setBuffer call in Cursor::insert(MathData const & ar) fixes the problem for
me.
Jürgen
Index: src/C
On 01/28/2010 12:01 PM, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
As I said, this is because you construct a new inset. If you follow my
advice and create an init() method, then the code will be simpler and
you won't need to set the buffer again.
I've no idea how this is supp
Enrico Forestieri wrote:
> Both crashes are avoided by the attached patch (in addition to yours).
Thanks, I added that.
> There's still something missing, though, as the refs are not updated
> the first time, but they are on successive attempts...
Yes, I noticed. These new refs do not have a val
On Thu, Jan 28, 2010 at 02:43:27PM +0100, Enrico Forestieri wrote:
> Both crashes are avoided by the attached patch (in addition to yours).
> There's still something missing, though, as the refs are not updated
> the first time, but they are on successive attempts...
I mean, cut&paste or insert t
On Thu, Jan 28, 2010 at 02:36:52PM +0100, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > Unfortunately the crash still occurs for me.
>
> Too bad, then I saw yet another crash.
>
> I'm out of time now, unfortunately.
Both crashes are avoided by the attached patch (in addition to yours)
Enrico Forestieri wrote:
> Unfortunately the crash still occurs for me.
Too bad, then I saw yet another crash.
I'm out of time now, unfortunately.
Jürgen
On Thu, Jan 28, 2010 at 12:57:23PM +0100, Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
> > Actually, we talked about different crashes. Yours is still there :-(
>
> It was a missing updateLabels() call in mathed. The attach addition fixes the
> problem for me. Please test.
Unfortunately
Jürgen Spitzmüller wrote:
> Actually, we talked about different crashes. Yours is still there :-(
It was a missing updateLabels() call in mathed. The attach addition fixes the
problem for me. Please test.
Jürgen
Index: src/mathed/InsetMathNest.cpp
Abdelrazak Younes wrote:
> As I said, this is because you construct a new inset. If you follow my
> advice and create an init() method, then the code will be simpler and
> you won't need to set the buffer again.
I've no idea how this is supposed to look.
Jürgen
Jürgen Spitzmüller wrote:
> If I add another manual setBuffer call in the paste helper, the problem
> disappears. This is pretty scary.
>
> Enrico, could you test this patch?
Actually, we talked about different crashes. Yours is still there :-(
Jürgen
On 01/28/2010 11:47 AM, Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
Another problem is that I get a crash when I cut and paste an existing
ref inset into a \text inset and then try to modify the referenced
label.
This is yet another uninitialized buffer_. No idea where that
Jürgen Spitzmüller wrote:
> > Another problem is that I get a crash when I cut and paste an existing
> > ref inset into a \text inset and then try to modify the referenced
> > label.
>
> This is yet another uninitialized buffer_. No idea where that comes from.
If I add another manual setBuffer c
Enrico Forestieri wrote:
> Good work, Jürgen. However, there are still some issues. The ref inset
> is not updated when it is inside a \tag or \text inset, for example.
OK, we also need to implement updateLabels in InsetMathNest. The attached
patch should fix this problem.
> Another problem is t
On Thu, Jan 28, 2010 at 08:23:35AM +0100, Jürgen Spitzmüller wrote:
> Anyone has an idea to improve that? If not, I'll commit.
Good work, Jürgen. However, there are still some issues. The ref inset
is not updated when it is inside a \tag or \text inset, for example.
Another problem is that I get
Abdelrazak Younes wrote:
> It's not that terrible but I guess you could create a new method
> CommandInset::init() instead of this gymnastic with params and strings :-)
I'll leave that for somebody else.
> Another comment: you don't need a default implementation of
> updateLabel() in InsetMath.
On 01/28/2010 08:23 AM, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
How you do that seems to be a bit compilcated. If I follow the
InsetMathHull::draw() function I'd think you need the following
functions:
InsetMathHull::updateLabels(); calls
InsetMathGrid::updateLabels(); calls
Math
Abdelrazak Younes wrote:
> > How you do that seems to be a bit compilcated. If I follow the
> > InsetMathHull::draw() function I'd think you need the following
> > functions:
> >
> > InsetMathHull::updateLabels(); calls
> > InsetMathGrid::updateLabels(); calls
> > MathData::updateLabels(); calls
>
On 01/27/2010 05:38 PM, Vincent van Ravesteijn - TNW wrote:
I suspect (but I am not sure) the problem is that InsetMathRefs are not
recorded in the paragraph's InsetList which is iterated for the label update.
If so, what do I have to do to change that?
I'm not really sure of what fo
>I suspect (but I am not sure) the problem is that InsetMathRefs are not
>recorded in the paragraph's InsetList which is iterated for the label update.
>If so, what do I have to do to change that?
I'm not really sure of what follows, but maybe it can give you a hint.
I think that the InsetMathR
I'm trying to fix bug 1560, which is about references in mathed not being
updated if their target labels are changed.
I'm trying to extend the reference cache to include InsetMathRefs, next to the
InsetRefs. Now the last obstacle seems to be that the new method
InsetMathRef::updateLabels does n
36 matches
Mail list logo
