On 11/20/2011 01:04 PM, Pavel Sanda wrote:
> Richard Heck wrote:
>> So, what to do? I see a couple options for branch:
> btw would these problems disappear if we postpone the fix for
> #7593 and readdress it in 2.0.3?
>
Yes, but I'm pretty confident about the latest version. And there were
other pr
Am Sonntag, 20. November 2011 um 12:38:00, schrieb Richard Heck
> Another option is attached. Now, each clone set has its own list of
> cloned buffers, and each clone has a pointer to this list, so there's no
> need to find the master buffer, etc. This should solve Kornel's crash,
> and it has th
Am Sonntag, 20. November 2011 um 19:01:09, schrieb Kornel Benko
> Am Sonntag, 20. November 2011 um 11:29:29, schrieb Richard Heck
>
> >
> > 3) As Vincent essentially noted, it's anyway wrong to clone all the
> > children, etc, when we are just doing autosave. The attached patch
> > addresses th
Richard Heck wrote:
> So, what to do? I see a couple options for branch:
btw would these problems disappear if we postpone the fix for
#7593 and readdress it in 2.0.3?
pavel
Am Sonntag, 20. November 2011 um 11:29:29, schrieb Richard Heck
>
> 3) As Vincent essentially noted, it's anyway wrong to clone all the
> children, etc, when we are just doing autosave. The attached patch
> addresses that issue. So with it, we won't see the assertion that Kornel
> reported. My w
Another option is attached. Now, each clone set has its own list of
cloned buffers, and each clone has a pointer to this list, so there's no
need to find the master buffer, etc. This should solve Kornel's crash,
and it has the advantage that it would allow us, in principle, to have
multiple export
Pavel reported a regression crash in branch in this thread:
http://marc.info/?t=12355291982&r=1&w=2&n=21
The problem turned out to be multiple deletions of cloned child buffers.
In this commit:
http://www.lyx.org/trac/changeset/40205
I tried to fix the crash by having so
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Helge Hafting wrote:
>> Perhaps something like [tabular lost!] or
>> [tabular paste currently unsupported],
>> so the user won't wonder what went wrong.
>
> I really wouldn't paste error messages into a document.
OK then. I thought we did something
Helge Hafting wrote:
> Perhaps something like [tabular lost!] or
> [tabular paste currently unsupported],
> so the user won't wonder what went wrong.
I really wouldn't paste error messages into a document.
Jürgen
Jürgen Spitzmüller wrote:
Jean-Marc Lasgouttes wrote:
So I just let Cursor::selectionAsString return an empty docstring()
with multi-cell selection. This breaks middle mouse pasting.
Why not return something like "[tabular]" instead?
Hm would you really want this?
Perhaps something like [ta
Jean-Marc Lasgouttes wrote:
> > So I just let Cursor::selectionAsString return an empty docstring()
> > with multi-cell selection. This breaks middle mouse pasting.
>
> Why not return something like "[tabular]" instead?
Hm would you really want this?
Jürgen
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> So I just let Cursor::selectionAsString return an empty docstring()
> with multi-cell selection. This breaks middle mouse pasting.
Why not return something like "[tabular]" instead?
JMarc
As you can reproduce with the attached test case, branch crashes if you select
all the cells starting from the last cell ending up in the first. The reason
is that Cursor::selectionAsString does not handle multiple cell selection and
mixes the cursor positions in the starting and ending cells (r
Andre Poenitz <[EMAIL PROTECTED]> writes:
>> > Which reminds me: I'd like to have 1.6.0 shipped with 'non-fatal
>> > asserts'.
>>
>> You mean instead of 'no asserts' as it is now?
>
> Yes.
Why not...
JMarc
On Fri, Mar 21, 2008 at 11:36:57PM +0100, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> > Which reminds me: I'd like to have 1.6.0 shipped with 'non-fatal
> > asserts'.
>
> You mean instead of 'no asserts' as it is now?
Yes.
Andre'
Andre Poenitz <[EMAIL PROTECTED]> writes:
> Which reminds me: I'd like to have 1.6.0 shipped with 'non-fatal
> asserts'.
You mean instead of 'no asserts' as it is now?
JMarc
On Fri, Mar 21, 2008 at 06:03:45PM +0100, Pavel Sanda wrote:
> errrm, crash in branch.
>
> > 1. insert figure float
> > 2. click on its label via middle mouse button.
> > 3. kaboom
> >
> > Program received signal SIGABRT, Aborted.
> > 0xe410 i
Pavel Sanda wrote:
> is the inset in uncollapsed state, yes?
yes.
What happens is that the Clipboard text is pasted before the inset (which is
what I'd expect).
Jürgen
> Pavel Sanda wrote:
> > errrm, crash in branch.
>
> cannot reproduce.
is the inset in uncollapsed state, yes?
pavel
Pavel Sanda wrote:
> errrm, crash in branch.
cannot reproduce.
Jürgen
errrm, crash in branch.
> 1. insert figure float
> 2. click on its label via middle mouse button.
> 3. kaboom
>
> Program received signal SIGABRT, Aborted.
> 0xe410 in __kernel_vsyscall ()
> (gdb) bt
> #0 0xe410 in __kernel_vsyscall ()
> #1 0xb705d101 in r
>> more observations:
>> -its under 1.5.5svn, cant reprudoce under 1.5.4.
>>
> fortunately its not under 1.6svn. there is one litte
> strange thing still - when you open such kind of file twice
> it creates two new files of the same name.
>
Please f
rgheck wrote:
rgheck wrote:
Juergen Spitzmueller wrote:
Pavel Sanda wrote:
more observations:
-its under 1.5.5svn, cant reprudoce under 1.5.4.
fortunately its not under 1.6svn. there is one litte
strange thing still - when you open such kind of file twice
it creates two new files of
rgheck wrote:
Juergen Spitzmueller wrote:
Pavel Sanda wrote:
more observations:
-its under 1.5.5svn, cant reprudoce under 1.5.4.
fortunately its not under 1.6svn. there is one litte
strange thing still - when you open such kind of file twice
it creates two new files of the same name.
rgheck wrote:
> I can also get it this way: Open a file; open the outliner; now
> File>Open "nonexistent.lyx":
can you try if reverting the following commit fixes the issue?
http://www.lyx.org/trac/changeset/23444
Jürgen
Juergen Spitzmueller wrote:
Pavel Sanda wrote:
more observations:
-its under 1.5.5svn, cant reprudoce under 1.5.4.
fortunately its not under 1.6svn. there is one litte
strange thing still - when you open such kind of file twice
it creates two new files of the same name.
Please
Pavel Sanda wrote:
>> more observations:
>> -its under 1.5.5svn, cant reprudoce under 1.5.4.
>
> fortunately its not under 1.6svn. there is one litte
> strange thing still - when you open such kind of file twice
> it creates two new files of the same name.
Please file a report with target 1.5.5.
> more observations:
> -its under 1.5.5svn, cant reprudoce under 1.5.4.
fortunately its not under 1.6svn. there is one litte
strange thing still - when you open such kind of file twice
it creates two new files of the same name.
pavel
> > 1. launch lyx, save file x, close lyx
> > 2. launch lyx, open file y, open outliner
> > 3. remove file x from disk
> > 4. try to open file x from file recent menu
> > 5. crash
> >
> > can anybody confirm?
>
> No (I get an empty file x).
> Do you have a backtrace?
that is the strange thing -
Pavel Sanda wrote:
> 1. launch lyx, save file x, close lyx
> 2. launch lyx, open file y, open outliner
> 3. remove file x from disk
> 4. try to open file x from file recent menu
> 5. crash
>
> can anybody confirm?
No (I get an empty file x).
Do you have a backtrace?
Jürgen
1. launch lyx, save file x, close lyx
2. launch lyx, open file y, open outliner
3. remove file x from disk
4. try to open file x from file recent menu
5. crash
can anybody confirm?
pavel
31 matches
Mail list logo
