Bo Peng wrote:
fix attached.
This fixes the crash but I think the correct behavior should be
keeping the cursor in its original paragraph and location, right?
That would be Abdel's patch.
Jürgen
Jürgen Spitzmüller wrote:
Bo Peng wrote:
Open the attached lyx file, move cursor to the end of the second line
(actually anywhere with pos length of previous line). Edit -
paragraph up, lyx crashes.
fix attached.
No, my patch is the right fix and I am responsible for this: in rev
19040, I
Abdelrazak Younes wrote:
No, my patch is the right fix and I am responsible for this: in rev
19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
Well, then put it in again, before I'll release the dogs ;-)
Jürgen
fix attached.
No, my patch is the right fix and I am responsible for this: in rev
19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
I produced exactly the same patch (5s later than you :-) ... please
commit if it works.
Cheers,
Bo
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
No, my patch is the right fix and I am responsible for this: in rev
19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
Well, then put it in again, before I'll release the dogs ;-)
Just let me the time to switch my repository
On 7/13/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote:
Abdelrazak Younes wrote:
No, my patch is the right fix and I am responsible for this: in rev
19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
Well, then put it in again, before I'll release the dogs ;-)
This makes me
Just let me the time to switch my repository to trunk :-)
Just to confirm that your patch works. Please put it in.
Bo
Bo Peng wrote:
Just let me the time to switch my repository to trunk :-)
Just to confirm that your patch works. Please put it in.
It's in already :-)
Abdel.
Bo Peng wrote:
On 7/13/07, Jürgen Spitzmüller
[EMAIL PROTECTED] wrote:
Abdelrazak Younes wrote:
No, my patch is the right fix and I am responsible for this: in rev
19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
Well, then put it in again, before I'll release the dogs ;-)
LyX can be scripted too thanks to the LFUNs...
Then we need to write a bunch of scripts to convert back and forth,
move, select, cut, paste, save/load, new/close window although I
do not think lyx can be manipulated like that externally.
Bo
Bo Peng wrote:
LyX can be scripted too thanks to the LFUNs...
Then we need to write a bunch of scripts to convert back and forth,
move, select, cut, paste, save/load, new/close window although I
do not think lyx can be manipulated like that externally.
Sure it can, one time I had a
Sure it can, one time I had a command sequence that launched LyX, opened
the UserGuide, scrolled it to the end, and exit LyX at the end. You can
put any LFUN in this command-sequence.
and check if lyx crashes, and if the pasted text is what you cut? I
guess the long term goal (?) is having
On 7/13/07, Bo Peng [EMAIL PROTECTED] wrote:
Kind of randomly, but frequently, when lyx exists, a dialog shows up and says:
The instruction at )x0190f7b0 referenced memory at 0x6d729b1. The
memory could not be written. Click OK to terminate the program.
Have not finally confirmed, but this
Bo Peng wrote:
On 7/13/07, Bo Peng [EMAIL PROTECTED] wrote:
Kind of randomly, but frequently, when lyx exists, a dialog shows up
and says:
The instruction at )x0190f7b0 referenced memory at 0x6d729b1. The
memory could not be written. Click OK to terminate the program.
Have not finally
You could disable the command window with the linker option /SUBSYSTEM:WINDOWS
Then, as far as I know, a command window will jump out whenever I run
some external command such as python that needs stdin/out.
Joost's lyx.exe/lyxc.exe solution is good enough.
BO
Kind of randomly, but frequently, when lyx exists, a dialog shows up and says:
The instruction at )x0190f7b0 referenced memory at 0x6d729b1. The
memory could not be written. Click OK to terminate the program.
Cheers,
Bo
Bo Peng wrote:
> Open the attached lyx file, move cursor to the end of the second line
> (actually anywhere with pos > length of previous line). Edit ->
> paragraph up, lyx crashes.
>
> Can any one confirm?
Yes. Please file a bug report.
> With the frequency of crashes
Bo Peng wrote:
Kind of randomly, but frequently, when lyx exists, a dialog shows up and
says:
The instruction at )x0190f7b0 referenced memory at 0x6d729b1. The
memory could not be written. Click OK to terminate the program.
Revision 19044 was perfect for me so it anything happened this must
Open the attached lyx file, move cursor to the end of the second line
(actually anywhere with pos > length of previous line). Edit ->
paragraph up, lyx crashes.
Can any one confirm?
With the frequency of crashes I am experiencing right now, I am
wondering if lyx 1.5.0 is really ready. :
> Can any one confirm?
cant confirm with rc2.
can confirm with svn.
pavel
> Revision 19044 was perfect for me so it anything happened this must be
> after this revision. Could it be related to the recent locale/language
> problems?
recent locale/language patches were reverted from tree.
pavel
Can any one confirm?
Confirmed under linux as well.
#0 0x003dcd22e21d in raise () from /lib64/tls/libc.so.6
#1 0x003dcd22fa1e in abort () from /lib64/tls/libc.so.6
#2 0x0096aee1 in lyx::support::abort () at src/support/abort.cpp:25
#3 0x004eda7b in
Bo Peng wrote:
Open the attached lyx file, move cursor to the end of the second line
(actually anywhere with pos > length of previous line). Edit ->
paragraph up, lyx crashes.
Can any one confirm?
Works fine with rev. 19044.
Abdel.
Bo Peng wrote:
Can any one confirm?
Confirmed under linux as well.
Obvious candidates for the brown paper bag:
http://www.lyx.org/trac/changeset/19057
http://www.lyx.org/trac/changeset/19046
#0 0x003dcd22e21d in raise () from /lib64/tls/libc.so.6
#1 0x003dcd22fa1e in abort ()
> Can any one confirm?
Yes. Please file a bug report.
I am investigating if there is a quick fix,... and Pavel says it is
introduced after rc2.
Well, obviously, nobody used this function until now. I'm confident that more
crashes will come to our attention once 1.5.0 is released.
It is not
Abdelrazak Younes wrote:
Bo Peng wrote:
Open the attached lyx file, move cursor to the end of the second line
(actually anywhere with pos > length of previous line). Edit ->
paragraph up, lyx crashes.
Can any one confirm?
Works fine with rev. 19044.
Wrong, I was using a release
Bo Peng wrote:
> Open the attached lyx file, move cursor to the end of the second line
> (actually anywhere with pos > length of previous line). Edit ->
> paragraph up, lyx crashes.
fix attached.
Jürgen
Index
I am investigating if there is a quick fix,... and Pavel says it is
introduced after rc2.
I guess it is something like:
P1: len 8
P2: len 20
Cursor: par = 2, pos = 20
after paragraph up
P1: len 20
P2: len 8
Cursor: par = 2, pos = 20
Fitcursor fails because pos > len. Looks like cursor needs
On 7/13/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
> Open the attached lyx file, move cursor to the end of the second line
> (actually anywhere with pos > length of previous line). Edit ->
> paragraph up, lyx crashes.
fix attached.
This fixes
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Obvious candidates for the brown paper bag:
http://www.lyx.org/trac/changeset/19057
Unlikely (this affects only LaTeX output).
http://www.lyx.org/trac/changeset/19046
Reverting this does not fix the crash.
I was wrong, see my other
Abdelrazak Younes wrote:
> Obvious candidates for the brown paper bag:
>
> http://www.lyx.org/trac/changeset/19057
Unlikely (this affects only LaTeX output).
> http://www.lyx.org/trac/changeset/19046
Reverting this does not fix the crash.
Jürgen
Jürgen Spitzmüller wrote:
Bo Peng wrote:
Open the attached lyx file, move cursor to the end of the second line
(actually anywhere with pos > length of previous line). Edit ->
paragraph up, lyx crashes.
Can any one confirm?
Yes. Please file a bug report.
With the frequency of crashe
Bo Peng wrote:
> > fix attached.
>
> This fixes the crash but I think the correct behavior should be
> keeping the cursor in its original paragraph and location, right?
That would be Abdel's patch.
Jürgen
Jürgen Spitzmüller wrote:
Bo Peng wrote:
Open the attached lyx file, move cursor to the end of the second line
(actually anywhere with pos > length of previous line). Edit ->
paragraph up, lyx crashes.
fix attached.
No, my patch is the right fix and I am responsible for this: in rev
Abdelrazak Younes wrote:
> No, my patch is the right fix and I am responsible for this: in rev
> 19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
Well, then put it in again, before I'll release the dogs ;-)
Jürgen
> fix attached.
No, my patch is the right fix and I am responsible for this: in rev
19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
I produced exactly the same patch (5s later than you :-) ... please
commit if it works.
Cheers,
Bo
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
No, my patch is the right fix and I am responsible for this: in rev
19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
Well, then put it in again, before I'll release the dogs ;-)
Just let me the time to switch my repository
On 7/13/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> No, my patch is the right fix and I am responsible for this: in rev
> 19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
Well, then put it in again, before I'll release the dogs ;-)
This makes
Just let me the time to switch my repository to trunk :-)
Just to confirm that your patch works. Please put it in.
Bo
Bo Peng wrote:
Just let me the time to switch my repository to trunk :-)
Just to confirm that your patch works. Please put it in.
It's in already :-)
Abdel.
Bo Peng wrote:
On 7/13/07, Jürgen Spitzmüller
<[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> No, my patch is the right fix and I am responsible for this: in rev
> 19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
Well, then put it in again, before I'll release the dogs
LyX can be scripted too thanks to the LFUNs...
Then we need to write a bunch of scripts to convert back and forth,
move, select, cut, paste, save/load, new/close window although I
do not think lyx can be manipulated like that externally.
Bo
Bo Peng wrote:
LyX can be scripted too thanks to the LFUNs...
Then we need to write a bunch of scripts to convert back and forth,
move, select, cut, paste, save/load, new/close window although I
do not think lyx can be manipulated like that externally.
Sure it can, one time I had a
Sure it can, one time I had a command sequence that launched LyX, opened
the UserGuide, scrolled it to the end, and exit LyX at the end. You can
put any LFUN in this command-sequence.
and check if lyx crashes, and if the pasted text is what you cut? I
guess the long term goal (?) is having
On 7/13/07, Bo Peng <[EMAIL PROTECTED]> wrote:
Kind of randomly, but frequently, when lyx exists, a dialog shows up and says:
The instruction at )x0190f7b0 referenced memory at 0x6d729b1. The
memory could not be written. Click OK to terminate the program.
Have not finally confirmed, but this
Bo Peng wrote:
> On 7/13/07, Bo Peng <[EMAIL PROTECTED]> wrote:
>> Kind of randomly, but frequently, when lyx exists, a dialog shows up
>> and says:
>>
>> The instruction at )x0190f7b0 referenced memory at 0x6d729b1. The
>> memory could not be written. Click OK to terminate the program.
>
> Have
You could disable the command window with the linker option /SUBSYSTEM:WINDOWS
Then, as far as I know, a command window will jump out whenever I run
some external command such as python that needs stdin/out.
Joost's lyx.exe/lyxc.exe solution is good enough.
BO
Uwe Stöhr wrote:
Could you please create a bugzilla (bugzilla.lyx.org) entry and
attach a sample file that
reproduce the problem?
There is now bug 3970:
http://bugzilla.lyx.org/show_bug.cgi?id=3970
I can confirm the crash with RC2.
What is important is trunk as I fixed some issue since
On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
Uwe Stöhr wrote:
Could you please create a bugzilla (bugzilla.lyx.org) entry and
attach a sample file that
reproduce the problem?
There is now bug 3970:
http://bugzilla.lyx.org/show_bug.cgi?id=3970
I can confirm the crash with RC2.
What
[EMAIL PROTECTED] wrote:
On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
Uwe Stöhr wrote:
Could you please create a bugzilla (bugzilla.lyx.org) entry and
attach a sample file that
reproduce the problem?
There is now bug 3970:
http://bugzilla.lyx.org/show_bug.cgi?id=3970
I can confirm
On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
Uwe Stöhr wrote:
Could you please create a bugzilla (bugzilla.lyx.org) entry and
attach a sample file that
reproduce the problem?
There is now bug 3970:
Uwe Stöhr wrote:
> Could you please create a bugzilla (bugzilla.lyx.org) entry and
attach a sample file that
> reproduce the problem?
There is now bug 3970:
http://bugzilla.lyx.org/show_bug.cgi?id=3970
I can confirm the crash with RC2.
What is important is trunk as I fixed some issue
On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
Uwe Stöhr wrote:
> Could you please create a bugzilla (bugzilla.lyx.org) entry and
attach a sample file that
> reproduce the problem?
There is now bug 3970:
http://bugzilla.lyx.org/show_bug.cgi?id=3970
I can confirm the crash with RC2.
[EMAIL PROTECTED] wrote:
On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
Uwe Stöhr wrote:
> Could you please create a bugzilla (bugzilla.lyx.org) entry and
attach a sample file that
> reproduce the problem?
There is now bug 3970:
http://bugzilla.lyx.org/show_bug.cgi?id=3970
I can confirm
On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
> On Wed, 4 Jul 2007, Abdelrazak Younes wrote:
>
>> Uwe Stöhr wrote:
>>> > Could you please create a bugzilla (bugzilla.lyx.org) entry and
>>> attach a sample file that
>>> > reproduce the problem?
>>>
>>> There is now
Could you please create a bugzilla (bugzilla.lyx.org) entry and attach a
sample file that
reproduce the problem?
There is now bug 3970:
http://bugzilla.lyx.org/show_bug.cgi?id=3970
I can confirm the crash with RC2.
regards Uwe
> Could you please create a bugzilla (bugzilla.lyx.org) entry and attach a
sample file that
> reproduce the problem?
There is now bug 3970:
http://bugzilla.lyx.org/show_bug.cgi?id=3970
I can confirm the crash with RC2.
regards Uwe
http://bugzilla.lyx.org/show_bug.cgi?id=3834
I suspect the crash happens in some circumstances, because : is not valid in
Windows file names, and boost::fs throws an exception in the given test case.
Now I wonder if it makes sense to have an icon file with a colon in the name
at all.
So I'd
put it in if it works...
-Original Message-
From: Jürgen Spitzmüller [mailto:[EMAIL PROTECTED]
Sent: Mon 6/25/07 13:05
To: LyX Devel
Subject: [tentative patch]: bug 3834: LyX crashes on startup
http://bugzilla.lyx.org/show_bug.cgi?id=3834
I suspect the crash happens in some
Leuven, E. wrote:
put it in if it works...
Actually, I'm not sure. I'm not on Windows and the reporter isn't able to
compile.
Jürgen
Jürgen == Jürgen Spitzmüller [EMAIL PROTECTED] writes:
Jürgen http://bugzilla.lyx.org/show_bug.cgi?id=3834 I suspect the
Jürgen crash happens in some circumstances, because : is not valid
Jürgen in Windows file names, and boost::fs throws an exception in
Jürgen the given test case. Now I wonder
Jean-Marc Lasgouttes wrote:
This looks good.
OK. I'll commit.
Jürgen
http://bugzilla.lyx.org/show_bug.cgi?id=3834
I suspect the crash happens in some circumstances, because ":" is not valid in
Windows file names, and boost::fs throws an exception in the given test case.
Now I wonder if it makes sense to have an icon file with a colon in the name
at all.
So I'd
put it in if it works...
-Original Message-
From: Jürgen Spitzmüller [mailto:[EMAIL PROTECTED]
Sent: Mon 6/25/07 13:05
To: LyX Devel
Subject: [tentative patch]: bug 3834: LyX crashes on startup
http://bugzilla.lyx.org/show_bug.cgi?id=3834
I suspect the crash happens in some
Leuven, E. wrote:
> put it in if it works...
Actually, I'm not sure. I'm not on Windows and the reporter isn't able to
compile.
Jürgen
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
Jürgen> http://bugzilla.lyx.org/show_bug.cgi?id=3834 I suspect the
Jürgen> crash happens in some circumstances, because ":" is not valid
Jürgen> in Windows file names, and boost::fs throws an exception in
Jürgen> the given test
Jean-Marc Lasgouttes wrote:
> This looks good.
OK. I'll commit.
Jürgen
Stefan Schimanski wrote:
Can you make a bug report about this flashing?
Done:
http://bugzilla.lyx.org/show_bug.cgi?id=3854
Jürgen
Stefan Schimanski wrote:
> Can you make a bug report about this flashing?
Done:
http://bugzilla.lyx.org/show_bug.cgi?id=3854
Jürgen
it looks like the cursor is very rapidly put inside the inset and back
outside. If I have the math panel toolbar opened (in auto mode), it
flashes
up shortly and disappears again. Also, the math inset itself
flashes and
something (which I cannot identify) pops up shortly. This is when I
it looks like the cursor is very rapidly put inside the inset and back
outside. If I have the math panel toolbar opened (in auto mode), it
flashes
up shortly and disappears again. Also, the math inset itself
"flashes" and
something (which I cannot identify) pops up shortly. This is when I
Stefan Schimanski wrote:
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=2446
The patch:
It seems to improve the situation (besides the crash, which is gone also
without your patch), but I still get some flashing effects when trying the
testcase of bug 2446 (screen flickering whenever I move
Am 09.06.2007 um 09:22 schrieb Jürgen Spitzmüller:
Stefan Schimanski wrote:
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=2446
The patch:
It seems to improve the situation (besides the crash, which is gone
also
without your patch), but I still get some flashing effects when
trying
Jürgen Spitzmüller wrote:
Alfredo Braunstein wrote:
I was hoping for the patch to be applied sooner, as
it was discussed enough, fixed a crash, and had some good side effects
(removal of the destroyed signals etc)...
But you wrote it's completely untested. If this is no more true, I'd say
Stefan Schimanski wrote:
Which kind of flashing?! What is flashing? The whole bufferview? The
math? Don't see any like that here.
rather the math.
it looks like the cursor is very rapidly put inside the inset and back
outside. If I have the math panel toolbar opened (in auto mode), it
Alfredo Braunstein wrote:
I tested it a few days without problems. I don't have svn rights ATM,
you should get them back as soon as possible IMHO. Then you're indebted to
contribute again ;-)
could someone else do it for me? Last version is in the 'road to rc2'
thread.
I'll do it.
Am Samstag, 9. Juni 2007 schrieb Jürgen Spitzmüller:
could someone else do it for me? Last version is in the 'road to rc2'
thread.
I'll do it.
But please write a log message.
Jürgen
Am 09.06.2007 um 11:07 schrieb Jürgen Spitzmüller:
Alfredo Braunstein wrote:
I tested it a few days without problems. I don't have svn rights ATM,
you should get them back as soon as possible IMHO. Then you're
indebted to
contribute again ;-)
could someone else do it for me? Last
And, if the inset = 0 it's a broken cursor in any way, no? So take
a wrong idx, hence inset=0. In the next loop with inset()==inset
will not cut if off. I think it's wrong.
I was right. You can crash it like this: abcde, insert ERT inset,
type inside fgh. Place the cursor behind the h.
Stefan Schimanski wrote:
> The bug: http://bugzilla.lyx.org/show_bug.cgi?id=2446
> The patch:
It seems to improve the situation (besides the crash, which is gone also
without your patch), but I still get some flashing effects when trying the
testcase of bug 2446 (screen flickering whenever I
Am 09.06.2007 um 09:22 schrieb Jürgen Spitzmüller:
Stefan Schimanski wrote:
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=2446
The patch:
It seems to improve the situation (besides the crash, which is gone
also
without your patch), but I still get some flashing effects when
trying
Jürgen Spitzmüller wrote:
> Alfredo Braunstein wrote:
>> I was hoping for the patch to be applied sooner, as
>> it was discussed enough, fixed a crash, and had some good side effects
>> (removal of the destroyed signals etc)...
>
> But you wrote it's "completely untested". If this is no more
Stefan Schimanski wrote:
> Which kind of flashing?! What is flashing? The whole bufferview? The
> math? Don't see any like that here.
rather the math.
it looks like the cursor is very rapidly put inside the inset and back
outside. If I have the math panel toolbar opened (in auto mode), it
Alfredo Braunstein wrote:
> I tested it a few days without problems. I don't have svn rights ATM,
you should get them back as soon as possible IMHO. Then you're indebted to
contribute again ;-)
> could someone else do it for me? Last version is in the 'road to rc2'
> thread.
I'll do it.
Am Samstag, 9. Juni 2007 schrieb Jürgen Spitzmüller:
> > could someone else do it for me? Last version is in the 'road to rc2'
> > thread.
>
> I'll do it.
But please write a log message.
Jürgen
Am 09.06.2007 um 11:07 schrieb Jürgen Spitzmüller:
Alfredo Braunstein wrote:
I tested it a few days without problems. I don't have svn rights ATM,
you should get them back as soon as possible IMHO. Then you're
indebted to
contribute again ;-)
could someone else do it for me? Last
And, if the inset = 0 it's a broken cursor in any way, no? So take
a wrong idx, hence inset=0. In the next loop with inset()==inset
will not cut if off. I think it's wrong.
I was right. You can crash it like this: "abcde", insert ERT inset,
type inside "fgh". Place the cursor behind the
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=2446
The patch:
Index: lyx-devel/src/Text3.cpp
===
--- lyx-devel.orig/src/Text3.cpp2007-06-08 17:51:19.0 +0200
+++ lyx-devel/src/Text3.cpp 2007-06-08
If we want multiple views and update the cursors when switching, we
should do it properly, maybe somehow similar to the patch below.
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=3785
Stefan
Index: lyx-devel/src/DocIterator.cpp
Stefan Schimanski wrote:
If we want multiple views and update the cursors when switching, we
should do it properly, maybe somehow similar to the patch below.
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=3785
Stefan
Or... just apply
Am 08.06.2007 um 20:05 schrieb Alfredo Braunstein:
Stefan Schimanski wrote:
If we want multiple views and update the cursors when switching, we
should do it properly, maybe somehow similar to the patch below.
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=3785
Stefan
Or... just apply
Stefan Schimanski wrote:
Grrr, it would be helpful if one puts a comment at a bug if one has a
patch. The subject of that thread is not really indicating that is
has something to do with the bug.
Yes, sorry about that... I was hoping for the patch to be applied sooner, as
it was discussed
Alfredo Braunstein wrote:
I was hoping for the patch to be applied sooner, as
it was discussed enough, fixed a crash, and had some good side effects
(removal of the destroyed signals etc)...
But you wrote it's completely untested. If this is no more true, I'd say go
ahead and apply it.
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=2446
The patch:
Index: lyx-devel/src/Text3.cpp
===
--- lyx-devel.orig/src/Text3.cpp2007-06-08 17:51:19.0 +0200
+++ lyx-devel/src/Text3.cpp 2007-06-08
If we want multiple views and update the cursors when switching, we
should do it properly, maybe somehow similar to the patch below.
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=3785
Stefan
Index: lyx-devel/src/DocIterator.cpp
Stefan Schimanski wrote:
> If we want multiple views and update the cursors when switching, we
> should do it properly, maybe somehow similar to the patch below.
>
> The bug: http://bugzilla.lyx.org/show_bug.cgi?id=3785
>
> Stefan
Or... just apply
Am 08.06.2007 um 20:05 schrieb Alfredo Braunstein:
Stefan Schimanski wrote:
If we want multiple views and update the cursors when switching, we
should do it properly, maybe somehow similar to the patch below.
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=3785
Stefan
Or... just apply
Stefan Schimanski wrote:
> Grrr, it would be helpful if one puts a comment at a bug if one has a
> patch. The subject of that thread is not really indicating that is
> has something to do with the bug.
Yes, sorry about that... I was hoping for the patch to be applied sooner, as
it was discussed
Alfredo Braunstein wrote:
> I was hoping for the patch to be applied sooner, as
> it was discussed enough, fixed a crash, and had some good side effects
> (removal of the destroyed signals etc)...
But you wrote it's "completely untested". If this is no more true, I'd say go
ahead and apply it.
Abdelrazak Younes wrote:
Year, that's a solution to the crash but still, there is something fishy
in there...
The problem is that inset-toggle exists in mathed, but is something pretty
different.
Jürgen
301 - 400 of 807 matches
Mail list logo
