So, this may have to be modified too.
> (gdb) p *start
> $38 = (const wchar_t &) @0x8b1e9c0: 49
> (gdb) x/5s 0x8b1e9c0
> 0x8b1e9c0: "1"
> 0x8b1e9c2: ""
> 0x8b1e9c3: ""
> 0x8b1e9c4: "$"
> 0x8b1e9c6: ""
> 0x8b1e9c7: ""
> 0x8b1e9c8: "s"
> 0x8b1e9ca: ""
> 0x8b1e9cb: ""
> 0x8b1e9cc: "\r
Also,
template< class Ch, class Tr, class Alloc>
basic_format:: basic_format(const string_type& s)
: style_(0), cur_arg_(0), num_args_(0), dumped_(false),
exceptions_(io::all_error_bits)
{
parse(s); }
it contains:
> (gdb) p &s
> $47 = (
> const
> I'm not quite sure about the data structure used here, but arguments fmt
> and arg1 in bformat() seem to contain no data fields:
Oh, I should assume &fmt and &arg1 contain pointers. Sorry.
> (gdb) p &fmt
> $44 = (const docstring *) 0xbfbfe588
> (gdb) p &arg1
> $46 = (docstring *) 0xbfbfe580
>
Georg Baum wrote:
If you want to debug this fdurther it might be a good idea to write a small
standalone program that simply calls boost::format with the problematic
input.
boost::basic_format() itself seems working if it is called with
"ordinary" strings:
> #include
> #include
>
> using n
behzad maha wrote:
hi
I want to do some coding help. My language is persian(farsi) and I
want to help Lyx support farsi.But I don't have experience coding for
multi-lingual documents.Can anyone help me where to start?
regards behzad
Hi, Behzad!
Mostafa Vahedi has recently done a
Sorry --- wrong patch attached! Here's the correct one (rather shorter ;) )
Dov Feldstern wrote:
Georg Baum wrote:
Stefan Schimanski wrote:
Then the question is only from which file format revision we start
with a lyx2lyx filter: from the change of the exporting behavior or
from the fix from
Stefan Schimanski wrote:
Here is a fix for the grey-bar bug, i.e. randomly only the current
paragraph is drawn and everything else is greyed out.
It'd be great if this fixed this bug. It's very annoying.
Richard
I think it is related to synthetic mouse event. Somehow a redraw is
triggered, b
Georg Baum wrote:
Stefan Schimanski wrote:
Then the question is only from which file format revision we start
with a lyx2lyx filter: from the change of the exporting behavior or
from the fix from today and the last days...
That depends on the format when the change happened. If it was during
> > confirmed. i filed the bug http://bugzilla.lyx.org/show_bug.cgi?id=3844 .
>
> Strange, I cannot reproduce.
svn up did the trick. current trunk is ok.
pavel
Alfredo Braunstein wrote:
> Pavel Sanda wrote:
>
>>> I just reproduced it on this file.
>>> Move cursor to the end of paragraph, then to start of work "tasks" do CR
>>> Move cursor to start of words "seller biased", then CR
>>> Move cursor to the start of "that for" then CR at that point lyx
>>>
W. Bentley MacLeod wrote:
When editing, and doing a carriage return, then backspace on the old
paragraph, carriage return, results in lyx 1.5.0rc1 crashing - 1.5 is
so much better than 1.4.4 in many respects I am trying to use it, but
this bug keeps occurring. I am using the windows version on
Pavel Sanda wrote:
>> I just reproduced it on this file.
>> Move cursor to the end of paragraph, then to start of work "tasks" do CR
>> Move cursor to start of words "seller biased", then CR
>> Move cursor to the start of "that for" then CR at that point lyx crashes.
>> ---
[EMAIL PROTECTED] wrote:
Hello,
I've compiled LyX 5.0 svn.
1) Open User Guide
2) Tools -> outline
3) Document -> Next cross-reference
4) Click in the Toc Widget on the second section
5) Boum with this (rather unhelpful message)
/usr/include/c++/4.1.3/debug/safe_iterator.h:130:error: attempt to
> I just reproduced it on this file.
> Move cursor to the end of paragraph, then to start of work "tasks" do CR
> Move cursor to start of words "seller biased", then CR
> Move cursor to the start of "that for" then CR at that point lyx crashes.
>
> When editing, and doing a carriage return, then backspace on the old
> paragraph, carriage return, results in lyx 1.5.0rc1 crashing - 1.5 is
i'm not able to reproduce it. can you provide exact steps how to achive
this crash ?
pavel
When editing, and doing a carriage return, then backspace on the old
paragraph, carriage return, results in lyx 1.5.0rc1 crashing - 1.5 is
so much better than 1.4.4 in many respects I am trying to use it, but
this bug keeps occurring. I am using the windows version on XP service
pack 2.
I pr
Am 09.06.2007 um 08:37 schrieb Martin Vermeer:
On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Critical bugs don't get less critical by ignorance. If
anybody
Stefan> wants to know more:
[snip]
Great
Dear all,
I reverted my previous patch that add @para to allow para to bypass
validation. The major problem is the handling @ in lyx2lyx.
In this patch, I add a check box 'bypass validation' that will allow
any listings parameters to be passed to lyx/latex if this checkboz is
checked. No file fo
On 6/9/07, Martin Vermeer <[EMAIL PROTECTED]> wrote:
On Sat, Jun 09, 2007 at 10:49:13AM -0500, Bo Peng wrote:
...
> +def revert_splitlayout(document):
> +r''' Revert SplitLayout to a lyx node
> +From
That would be 'note'
Will be corrected when applied.
Thanks.
Bo
On Sat, Jun 09, 2007 at 10:49:13AM -0500, Bo Peng wrote:
...
> +def revert_splitlayout(document):
> +r''' Revert SplitLayout to a lyx node
> +From
That would be 'note'
...
- Martin
There's no other possibility IMO.
That is *too much* work!
I will propose, instead,
1. revert my @ idea
2. add a checkbox like 'bypass validation', 'use what I have inputted'.
3. if this checkbox is clicked, the parameter is allowed.
In this way, there will be no lyx2lyx problem.
Agreed?
Bo
Jürgen Spitzmüller schrieb:
Michael Gerz wrote:
for (; cur; cur.forwardChar())
- if (cur.inTexted() && match(cur.paragraph(), cur.pos()))
+ if (cur.inTexted() &&
+ (find_del || !cur.paragraph().isDeleted(cur.pos())) &&
+ match(cur.
Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3830
The patch should be obvious.
Stefan
Index: lyx-devel/src/mathed/MathMacro.cpp
===
--- lyx-devel.orig/src/mathed/MathMacro.cpp 2007-06-02
11:24:05.0 +0200
+++ lyx-devel/src
Michael Gerz wrote:
> > for (; cur; cur.forwardChar())
> > - if (cur.inTexted() && match(cur.paragraph(), cur.pos()))
> > + if (cur.inTexted() &&
> > + (find_del || !cur.paragraph().isDeleted(cur.pos())) &&
> > + match(cur.paragraph(), c
Jürgen,
your patch looks nice in general. I can imagine that it even fixes #3160. Below
please find some additional comments.
Michael
Index: src/lyxfind.cpp
===
--- src/lyxfind.cpp (Revision 18711)
+++ src/lyxfind.cpp (Ar
Michael Gerz wrote:
> IMHO, "find & replace" should always ignore deleted text, in CT mode as
> well as in non-CT mode.
That's what my patch does. I'm just waiting for your testing.
Jürgen
Bo Peng wrote:
> > But we have to maintain backwards compatibility also within the 1.5
> > cycle. And is the backwards compatibility to 1.4 assured? I.e., will
> > @extraparams be reverted to ERT correctly?
>
> I see a point here. When reverting to ERT, @ needs to be removed. I
> will commit a patc
Helge Hafting schrieb:
If you turn off change tracking and edit, then surely all new stuff
should
be without the change tracking markings. (i.e. not deleted or marked
as inserted by someone.) You may be able to add inside a deleted region,
but that should split the deleted region in two.
That'
But we have to maintain backwards compatibility also within the 1.5 cycle.
And is the backwards compatibility to 1.4 assured? I.e., will @extraparams be
reverted to ERT correctly?
I see a point here. When reverting to ERT, @ needs to be removed. I
will commit a patch soon.
IMHO , the only way
Bennett Helm schrieb:
I agree with the last sentence, but notice that the patch doesn't do
this! When change tracking is turned off, it is entirely possible to
delete -- remove from the file -- text that is marked as deleted.
Right. Even if we prohibited it, the user may always accept deleted te
Bo Peng wrote:
> I would not consider rc1 because it is a temporary release. After
> 1.5.0, @para will always be accepted and will compile if a user's
> listings package supports para.
But we have to maintain backwards compatibility also within the 1.5 cycle.
And is the backwards compatibility to
Bo Peng wrote:
Herbert> The current behaviour is easy!
But not so easy for lyx newbies. The question is: what to insert that
do not show up in the screen output (better latex output), yet split
the environment? I remember that it took me 10 minutes to figure that
out a few years ago.
And, as I'v
Jean-Marc Lasgouttes wrote:
Another solution is to remove this special handling for
environments and force to use depth when several paragraphs are in
a same env.
Richard> But the many-paragraphs case isn't that exceptional and, in
Richard> some cases, is even the most common. So it seems
I prefer normalsize roman font and red (like beamer pause/endFrame) or blue
(like pagebreak).
That will be the attached, which has the following style entry:
Style SplitLayout
KeepEmpty 1
MarginDynamic
LatexType Paragraph
But what happens if a file with such a parameter is opened by an older version
(rc1, for instance)? I guess LyX will crash, no?
I would not consider rc1 because it is a temporary release. After
1.5.0, @para will always be accepted and will compile if a user's
listings package supports para.
Of
> Yes, in the long term this is a solution. But currently we rely on Qt 4.1,
> so I hope it could go in for 1.5.
i hope so :)
pavel
Pavel Sanda wrote:
I agree with Pavel.
>>> I not, because I don't like such buttons.
>> I like the patch like it is. Single tab buttons take screen space and
>> clutter the appearance.
>
> i suppose it wont be problem to make switch between these two appearances in
> preferences when the se
Bo Peng wrote:
> No. Previously, only valid parameter strings such as 'firstline=5' are
> allowed. Now, trashes like '@IamTrash,firstline=5' can also be
> entered, although in this particular case latex will not compile
> (wrong parameter IamTrash).
But what happens if a file with such a parameter
[EMAIL PROTECTED] wrote:
Hello,
I've compiled LyX 5.0 svn.
1) Open User Guide
2) Tools -> outline
3) Document -> Next cross-reference
Here (Win/MSVC) it crashes at point 3 with this backtrace:
lyx-qt4.exe!lyx::frontend::TocModel::modelIndex(const
std::_Vector_const_iterator >
& it={par_
On 6/9/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> Allow prefixing a listings parameter with @ to bypass validation, useful
> when new parameters are added in a new listings version
Isn't this a file format change?
No. Previously, only valid parameter strings s
[EMAIL PROTECTED] wrote:
> Allow prefixing a listings parameter with @ to bypass validation, useful
> when new parameters are added in a new listings version
Isn't this a file format change?
Jürgen
I think the proper way to solve any option would have been to outsource
the option definitions in a text file which is easily upgradable.
But then 1.5.0 will not be usable for listings 2009... Adding a
backdoor is always safer. :-)
Bo
Bo Peng wrote:
I see no comment on this patch. Because this is within my field, I
will commit tomorrow if there is no objection.
No objection, so it is in.
I think the proper way to solve any option would have been to outsource
the option definitions in a text file which is easily upgradable
Bo Peng wrote:
> We have not done anything, and if the operators are cheap as you
> described, it is perfectly fine to me to make TocUpdate automatic.
Good, thanks.
But then it is your job to get it done. :-)
I am slowly coming back, don't ask me too much ;-)
Seriously, as we have discuss
I see no comment on this patch. Because this is within my field, I
will commit tomorrow if there is no objection.
No objection, so it is in.
Cheers,
Bo
Am 09.06.2007 um 15:05 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 09.06.2007 um 14:46 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Ok, committed. So let's see if everything is alright now. We
still have some days to the RC2 for testing.
If the testing reveals that we do
behzad maha wrote:
hi
I want to do some coding help. My language is persian(farsi) and I
want to help Lyx support farsi.But I don't have experience coding for
multi-lingual documents.Can anyone help me where to start?
Hello Behzad,
We have already a Farsi developper around (Mostafa Vahedi). In
> We have not done anything, and if the operators are cheap as you
> described, it is perfectly fine to me to make TocUpdate automatic.
Good, thanks.
But then it is your job to get it done. :-)
Seriously, as we have discussed, the problem lies in 'when to update
Toc'. It is unwise to update To
Bo Peng wrote:
Please don't touch at that. When you change a section depth, the full
renumbering is done (in updateLabels()). It is only natural to update
also the TocBackend at the same time. Actually this update is much
quicker than the section renumbering.
We have not done anything, and if t
InsetMathMBox is compiled only with CMake. That's because I wanted to
make sure that it stays compilable until it's time to use it.
I was thinking that scons (or worse, gcc) is broken. :-)
Bo
Stefan Schimanski wrote:
Am 09.06.2007 um 14:46 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Ok, committed. So let's see if everything is alright now. We still
have some days to the RC2 for testing.
If the testing reveals that we don't need the Inset::destroyed()
signal, this should
Please don't touch at that. When you change a section depth, the full
renumbering is done (in updateLabels()). It is only natural to update
also the TocBackend at the same time. Actually this update is much
quicker than the section renumbering.
We have not done anything, and if the operators are
Stefan Schimanski wrote:
Am 09.06.2007 um 14:46 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Ok, committed. So let's see if everything is alright now. We still
have some days to the RC2 for testing.
If the testing reveals that we don't need the Inset::destroyed()
signal, this should
Am 09.06.2007 um 14:46 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Ok, committed. So let's see if everything is alright now. We still
have some days to the RC2 for testing.
If the testing reveals that we don't need the Inset::destroyed()
signal, this should be deleted before RC2 t
Stefan Schimanski wrote:
Ok, committed. So let's see if everything is alright now. We still have
some days to the RC2 for testing.
If the testing reveals that we don't need the Inset::destroyed() signal,
this should be deleted before RC2 too.
Abdel.
[EMAIL PROTECTED] wrote:
> Done
Thanks. I confirmed it and targetted it to 1.5.0.
Jürgen
Bo Peng wrote:
The way to solve this might be to put some appropriate code into
InsetCaption::notifyCursorLeaves().
I do not think it is a good idea to update Toc during editing, because
simple add/remove of sections, change of environment will break Toc,
so it is close to impossible to conside
Ok, committed. So let's see if everything is alright now. We still
have some days to the RC2 for testing.
Stefan
Am 09.06.2007 um 14:32 schrieb Alfredo Braunstein:
Abdelrazak Younes wrote:
Stefan Schimanski wrote:
It works fine (as far as I can judge after 2 minutes testing). I
added
som
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>> Why do we have a BufferView for every window instead of one for every
>> tab? The latter would be a much simpler scheme...
>
> The plan is to have one BufferView per Buffer for a given window. The
> plan is also to have one WorkArea per tab,
Stefan Schimanski wrote:
drawMarkers moved to InsetMathNest?! See r18701. Please revert or fix that.
/Users/sts/Quellen/mac/lyx-devel/src/mathed/InsetMathMBox.cpp: In member
function 'virtual void lyx::InsetMathMBox::draw(lyx::PainterInfo&, int,
int) const':
/Users/sts/Quellen/mac/lyx-devel/sr
Done
#3843
Richard Heck wrote:
Bo Peng wrote:
The way to solve this might be to put some appropriate code into
InsetCaption::notifyCursorLeaves().
I do not think it is a good idea to update Toc during editing, because
simple add/remove of sections, change of environment will break Toc,
so it is close to
Here is a fix for the grey-bar bug, i.e. randomly only the current
paragraph is drawn and everything else is greyed out.
I think it is related to synthetic mouse event. Somehow a redraw is
triggered, but the ViewMetric.update_strategy is set to
NoScreenUpdate. The two condition, that I chan
Abdelrazak Younes wrote:
> Stefan Schimanski wrote:
>> It works fine (as far as I can judge after 2 minutes testing). I added
>> some comments and pulled apart the loop to make the control flow easier.
>> Alfredo, can you check please? I would be happy if we could get rid of
>> the signals finally
Bo Peng wrote:
Bo> Fixed in the attached patch. Jose, OK to apply?
I am not very pleased with the use of an exception there, but on the
other hand I do not have (yet) a better idea.
I though of returning TocItem and let update() add the labels.
However, ParConstIterator does not have a default
Alfredo Braunstein wrote:
Why do we have a BufferView for every window instead of one for every tab?
The latter would be a much simpler scheme...
The plan is to have one BufferView per Buffer for a given window. The
plan is also to have one WorkArea per tab, thus one BufferView per tab.
At th
Stefan Schimanski wrote:
It works fine (as far as I can judge after 2 minutes testing). I added
some comments and pulled apart the loop to make the control flow easier.
Alfredo, can you check please? I would be happy if we could get rid of
the signals finally like this.
I am not Alfredo but i
Am 09.06.2007 um 13:09 schrieb Alfredo Braunstein:
Stefan Schimanski wrote:
It works fine (as far as I can judge after 2 minutes testing). I
added some comments and pulled apart the loop to make the control
flow easier. Alfredo, can you check please? I would be happy if we
could get rid of th
Le 8 juin 07 à 10:28, Mael Hilléreau a écrit :
What is the status of this patch?
What do you mean by "status" exactly? I don't know if it was tested
by others than me. But to be integrated, it is clear that the code
needs more testing, and then some #ifdefs in order to be applied
only to
Stefan Schimanski wrote:
> It works fine (as far as I can judge after 2 minutes testing). I
> added some comments and pulled apart the loop to make the control
> flow easier. Alfredo, can you check please? I would be happy if we
> could get rid of the signals finally like this.
Sure, but I cannot
> >>I agree with Pavel.
> >
> >I not, because I don't like such buttons.
>
> I like the patch like it is. Single tab buttons take screen space and
> clutter the appearance.
i suppose it wont be problem to make switch between these two appearances in
preferences when the second is available.
p
Le 9 juin 07 à 12:30, Jürgen Spitzmüller a écrit :
Mael Hilléreau wrote:
May I file an enhancement request at bugzilla?
Yes, please do so (this is something for post-1.5.0).
Done: http://bugzilla.lyx.org/show_bug.cgi?id=3842
Mael.
It works fine (as far as I can judge after 2 minutes testing). I
added some comments and pulled apart the loop to make the control
flow easier. Alfredo, can you check please? I would be happy if we
could get rid of the signals finally like this.
Stefan
Index: lyx-devel/src/CursorSlice.cpp
Jean-Marc Lasgouttes wrote:
> It is completely different: dEPM disallows things that have _no_
> meaning to LaTeX (like double space). And empty math inset is
> acceptable, even if it is most of the times not wanted.
sure, perhaps latex permits this but when would you want to create an empty
math
Stefan Schimanski wrote:
>>> Some small questions:
>>> Why don't you like comments?
>>
>> ? Be more specific. OTOH, I would have like some comment of yours
>> when I
>> asked for them a week ago... ;-)
>
> Sorry, meant something like two lines describing what the big loop is
> doing. Not the comm
Mael Hilléreau wrote:
> May I file an enhancement request at bugzilla?
Yes, please do so (this is something for post-1.5.0).
Jürgen
Stefan Schimanski wrote:
> I guess yes. Compiling right now. If it does, that would be great.
> Signals in those CursorSlices, always feel in a strange way when
> thinking about it :)
Since you are at it, could you please just commit if you think it is correct?
Jürgen
Le 8 juin 07 à 12:15, Mael Hilléreau a écrit :
Le 6 juin 07 à 16:58, Richard Heck a écrit :
Mael Hilléreau wrote:
Le 6 juin 07 à 15:54, Richard Heck a écrit :
Mael Hilléreau wrote:
I'm on Mac OS 10.4.9, with 1.5.0rc1. In the two following
situations, the outline panel is hidden whereas it
Some small questions:
Why don't you like comments?
? Be more specific. OTOH, I would have like some comment of yours
when I
asked for them a week ago... ;-)
Sorry, meant something like two lines describing what the big loop is
doing. Not the comments here :)
Why do you need this compli
Stefan Schimanski wrote:
> Some small questions:
> Why don't you like comments?
? Be more specific. OTOH, I would have like some comment of yours when I
asked for them a week ago... ;-)
> Why do you need this complicated logic to set the inset to 0 in many
> cases. Won't that end the loop anyway
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.
Hi!
Is there a reason that the non-modal dialogs (like to edit tables,
change text styles etc.) depend on the LyX window? You can open
another one for every window which is open. It's somehow strange and
confusing to have a text style dialog, but it "doesn't work" because
it belongs to an
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 versio
Am 09.06.2007 um 00:28 schrieb Alfredo Braunstein:
Jean-Marc Lasgouttes wrote:
Yes, the patch looks good, except that the messages are not very
informative (but as a usr I would be scared to see all these messages
in normal operation). And there is a very long line.
Fixed. Note that the sca
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
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.
Jür
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 flas
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 tru
Am 09.06.2007 um 09:52 schrieb Peter Kümmel:
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
Firefox also had only one button in the 1.5 series. And I don't
like
the 2.x UI with the button per tab.
please dont close the bug for close button on tab.
the main advantage of one button per tab is
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 the
[EMAIL PROTECTED] wrote:
> 1) Open User Guide
> 2) Tools -> outline
> 3) Document -> Next cross-reference
> 4) Click in the Toc Widget on the second section
> 5) Boum
Confirmed (backtrace below).
Please file a bug report.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
>>> Firefox also had only one button in the 1.5 series. And I don't like
>>> the 2.x UI with the button per tab.
>> please dont close the bug for close button on tab.
>> the main advantage of one button per tab is the possibility to close
>> different
Hello,
I've compiled LyX 5.0 svn.
1) Open User Guide
2) Tools -> outline
3) Document -> Next cross-reference
4) Click in the Toc Widget on the second section
5) Boum with this (rather unhelpful message)
/usr/include/c++/4.1.3/debug/safe_iterator.h:130:error: attempt to copy-
construct an ite
Martin Vermeer wrote:
On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Critical bugs don't get less critical by ignorance. If anybody
Stefan> wants to know more:
[snip]
Great analysis!
I
Pavel Sanda wrote:
> > Firefox also had only one button in the 1.5 series. And I don't like
> > the 2.x UI with the button per tab.
>
> please dont close the bug for close button on tab.
> the main advantage of one button per tab is the possibility to close
> different tabs just by one click withou
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 mov
96 matches
Mail list logo