tommaso wrote:
> Author: tommaso
> Date: Fri Jan 29 08:29:25 2010
> New Revision: 33252
> URL: http://www.lyx.org/trac/changeset/33252
>
> Log:
> Changed "from begin" to "from the beginning", as suggested by gmatht (in
> #6478)
Tommaso, this is not the way to do that. You need to change the stri
bb wrote:
I remeber that in older lyx-versions it was possible to mark
anhyphenation by CTR+"-". In my version 1.6.5 on linux this is not
worging any more.
It still works for me.
Vincent
I remeber that in older lyx-versions it was possible to mark
anhyphenation by CTR+"-". In my version 1.6.5 on linux this is not
worging any more.
Is this a bug?
Regards BB
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
> I would like to initiate the pasting behavior in equation arrays that
> has changed at some time and disturbs me since that.
I should have checked my text again before sending it a second time...
I meant "I would like to initiate a discussion on the pasting
behavior..."
- Sebastian
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,
Thanks for all the hints. Made me being able to check Jürgens
label-bugfix in the new lyx. Like it so far :-)
On Thu, 2010-01-28 at 10:31 -0500, rgheck wrote:
> On 01/28/2010 10:22 AM, Jürgen Spitzmüller wrote:
> > Sebastian Guttenberg wrote:
> >
> >> Thanks a lot. Had to type it quite often,
(Sorry, last email was not complete yet, I have hit ctrl-return before it was
complete.
Happens always to me in this f*ing evolution-program)
Hi all
I would like to initiate the pasting behavior in equation arrays that
has changed at some time and disturbs me since that.
As it is now, if a cell
Hi all
I would like to initiate the pasting behavior in equation arrays that
has changed at some time and disturbs me since that.
As it is now, if a cell already has some content, then the content of a
pasted cell is always added at the beginning, no matter where the cursor
is. I know that it will
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
On 01/28/2010 10:22 AM, Jürgen Spitzmüller wrote:
Sebastian Guttenberg wrote:
Thanks a lot. Had to type it quite often, but it's fine now.
Next time just delete all *.po files and svn up. Those *.po conflicts just
happen, once in a while.
Or just revert them. That's what I usual
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
Sebastian Guttenberg wrote:
> Thanks a lot. Had to type it quite often, but it's fine now.
Next time just delete all *.po files and svn up. Those *.po conflicts just
happen, once in a while.
Jürgen
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
The index M in \overleftarrow{\partial}_M is displayed in lyx as being
below the \partial while after the Latex run it is correctly displayed
in the dvi-file. Behavior also occurs for \overrightarrow and perhaps
other related boxes. Nothing severe though. No beer for that one ;-)
- Sebastian
> type "tf".
>
> Jürgen
Thanks a lot. Had to type it quite often, but it's fine now.
- Sebastian
Sebastian Guttenberg wrote:
> Can anyone tell me how I should proceed?
type "tf".
Jürgen
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
Sebastian Guttenberg wrote:
> Hi all
> I am getting a conflict when I do "svn update" for lyx2.0svn:
>
> "...
> Ulib/Makefile.am
> Ulib/ui/default.ui
> Ulib/ui/stdcontext.inc
> Ulib/ui/stdtoolbars.inc
> Ulib/ui/stdmenus.inc
> Conflict discovered in 'po/cs.po'.
> Select: (p) pos
Hi all
I am getting a conflict when I do "svn update" for lyx2.0svn:
"...
Ulib/Makefile.am
Ulib/ui/default.ui
Ulib/ui/stdcontext.inc
Ulib/ui/stdtoolbars.inc
Ulib/ui/stdmenus.inc
Conflict discovered in 'po/cs.po'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine
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:
> A static cast:
>
> static_cast or static_cast
>
>
> A static cast is OK here because we are sure that this is indeed an
> InsetCommand. Dynamic casts are in general used in case of multiple
> inheritance. It's a runtime thing and thus slower than a static cast
> wh
On 01/28/2010 10:19 AM, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
+ if (oldname != newname) {
+ // adapt the references
+ for (InsetIterator itt =
inset_iterator_begin(in);
+
Abdelrazak Younes wrote:
> > + if (oldname != newname) {
> > + // adapt the references
> > + for (InsetIterator itt =
> > inset_iterator_begin(in);
> > +itt != i_en
On 01/28/2010 09:33 AM, sp...@lyx.org wrote:
Author: spitz
Date: Thu Jan 28 09:33:14 2010
New Revision: 33240
URL: http://www.lyx.org/trac/changeset/33240
Log:
* InsetTabular.{cpp, h}:
- implement addToToc (bug 6372).
Side note: we should use #6372 so that track automatically insert a
On 01/28/2010 08:29 AM, sp...@lyx.org wrote:
Author: spitz
Date: Thu Jan 28 08:29:57 2010
New Revision: 33239
URL: http://www.lyx.org/trac/changeset/33239
Log:
When pasting a math inset with a label, check for duplicates (as we do outside
math)
(bug 6218)
Modified:
lyx-devel/branches/BRANC
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
spitz wrote:
> Author: spitz
> Date: Thu Jan 28 09:33:14 2010
> New Revision: 33240
> URL: http://www.lyx.org/trac/changeset/33240
>
> Log:
> * InsetTabular.{cpp, h}:
> - implement addToToc (bug 6372).
Also a candidate for branch.
Objections, comments?
Jürgen
52 matches
Mail list logo
