Sven Hoexter wrote:
Hi,
while preparing a Debian package for the upcoming 1.5 release I've
experienced a huge performance problem with 1.5rc1. Now I tried to find a
reason and had to find out that the current trunk will segfault when I build
it with the boost libs provided in the Debian
Bo Peng wrote:
This patch properly shut down what's needed to avoid the crashes.
OK?
I do not know this part of the code so you decide. Also, I did not use
multi-view when I had the crashes.
I suppose it depends on the machine and on when the statusbar timer was
timed out.
Anyway, this
On Sun, Jul 15, 2007 at 10:18:03AM +0200, Peter Kümmel wrote:
Sven Hoexter wrote:
Hi,
while preparing a Debian package for the upcoming 1.5 release I've
experienced a huge performance problem with 1.5rc1. Now I tried to find a
reason and had to find out that the current trunk will
Dov Feldstern wrote:
We create the 1.5.x branch *now*, but don't release yet.
That depends on how Juergen will manage the stable series. I
personally would like that we continue trunk development on the 1.5
series instead of opening a new 1.5.x branch. I would like to propose
that we
Sven Hoexter wrote:
On Sun, Jul 15, 2007 at 10:18:03AM +0200, Peter Kümmel wrote:
Sven Hoexter wrote:
Hi,
while preparing a Debian package for the upcoming 1.5 release I've
experienced a huge performance problem with 1.5rc1. Now I tried to find a
reason and had to find out that the current
On Sun, Jul 15, 2007 at 03:18:35AM +0300, Dov Feldstern wrote:
Joost Verburg wrote:
Abdelrazak Younes wrote:
Quite frankly, as there is no format change and that this needs some more
testing, I'd prefer that you wait for 1.5.1 which will hopefully happen
very soon. Just look at my
On Sun, Jul 15, 2007 at 11:19:50AM +0200, Abdelrazak Younes wrote:
Dov Feldstern wrote:
We create the 1.5.x branch *now*, but don't release yet.
That depends on how Juergen will manage the stable series. I personally
would like that we continue trunk development on the 1.5 series
Peter Kümmel wrote:
Maybe someone has an idea:
74 LyXView::LyXView(int id)
75 : work_area_(0),
76toolbars_(new Toolbars(*this)),
77autosave_timeout_(new Timeout(5000)),
78dialogs_(new Dialogs(*this)),
79
Abdelrazak Younes wrote:
Dov Feldstern wrote:
We create the 1.5.x branch *now*, but don't release yet.
That depends on how Juergen will manage the stable series. I
personally would like that we continue trunk development on the 1.5
series instead of opening a new 1.5.x branch. I would like
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Maybe someone has an idea:
74 LyXView::LyXView(int id)
75 : work_area_(0),
76 toolbars_(new Toolbars(*this)),
77 autosave_timeout_(new Timeout(5000)),
78 dialogs_(new Dialogs(*this)),
79
Abdelrazak Younes wrote:
Hum, maybe the problem is in our side and not boost. This comment and
code in frontends/Dialogs.cpp seems suspicious to me:
Yes, once again a static variable.
// Note that static boost signals break some compilers, so this wrapper
// initialises the signal
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Maybe someone has an idea:
74 LyXView::LyXView(int id)
75 : work_area_(0),
76 toolbars_(new Toolbars(*this)),
77 autosave_timeout_(new Timeout(5000)),
78
Abdelrazak Younes wrote:
Hum, maybe the problem is in our side and not boost. This comment and
code in frontends/Dialogs.cpp seems suspicious to me:
Yes, once again a static variable.
// Note that static boost signals break some compilers, so this wrapper
// initialises the signal
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Dov Feldstern wrote:
We create the 1.5.x branch *now*, but don't release yet.
That depends on how Juergen will manage the stable series. I
personally would like that we continue trunk development on the 1.5
series instead of opening a new
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove BugfixSignal, and
create the signal at runtime. But we then have to clean up correctly.
Your solution will only work with the first instance...
Abdelrazak Younes wrote:
I don't see the advantage of this. I'd rather do a 1.5.x branch and let
people do some more adventourous development (or new features) in trunk.
I am thinking of GUI development. Dialogs, context menu, etc...
I don't see why this cannot happen in the current scheme
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we then have to clean up correctly.
Your solution will only work
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we then have to clean up correctly.
Your solution will only work
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I don't see the advantage of this. I'd rather do a 1.5.x branch and let
people do some more adventourous development (or new features) in trunk.
I am thinking of GUI development. Dialogs, context menu, etc...
I don't see why this cannot
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we then have to clean up correctly.
Your solution
Hi,
I would love to have frontend support for \cancel{} which strikes out
parts in a formula as provided by cancel.sty. Looking at the svn it
seems to be pretty analog to e.g. implementing \sqrt{}. So I would like
to try this myself. I have c programming experience but no c++. Also it
looks as I
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we then have to clean up
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we then have to clean up
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create
Abdelrazak Younes wrote:
In the current scheme new feature will have to wait one year minimum
before going to the public. In my proposed scheme new feature will be
available every 3 month.
Why that?
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
In the current scheme new feature will have to wait one year minimum
before going to the public. In my proposed scheme new feature will be
available every 3 month.
Why that?
Why that what? You think that 1.6 will come in less than a year?
Abdelrazak Younes wrote:
The only solution is just to get rid of this BugfixSignal. Actually,
this hideSignal is not needed at all!
Something like the attached. I guess this signal was needed at some
point but not anymore.
Updated patch attached.
Abdel.
Index: frontends/Dialogs.cpp
Abdelrazak Younes wrote:
Why that?
Why that what? You think that 1.6 will come in less than a year?
No. Why do you think new features cannot go into the stable series? As I've
outlined, I'm very open to backporting features that are tested and
straightforward (at least after 1.5.1). This
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Why that?
Why that what? You think that 1.6 will come in less than a year?
No. Why do you think new features cannot go into the stable series? As I've
outlined, I'm very open to backporting features that are tested and
straightforward (at
Abdelrazak Younes wrote:
Hum, maybe the problem is in our side and not boost. This comment and
code in frontends/Dialogs.cpp seems suspicious to me:
// Note that static boost signals break some compilers, so this wrapper
// initialises the signal dynamically when it is first invoked.
Abdelrazak Younes wrote:
As soon as do some cleanups (like I've done in my mvc branch)
back-porting will get more and more complicated. Backporting will
require additional work whereas developing feature and doing cleanup
directly in the stable branch will not.
I see your point, but IMHO a
Jürgen Spitzmüller wrote:
effort (but that's exactly the point where our opinions differ).
Exactly ;-)
Abdel.
Roger Mc Murtrie wrote:
Is there any relationship between this problem and Bug 4014, Comment 16
due to some changes in boost?
I don't think so.
Abdel.
On Sun, Jul 15, 2007 at 12:08:13PM +0200, Peter Kümmel wrote:
Hi,
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove BugfixSignal, and
create the signal at runtime. But we then have to clean up correctly.
Ok I tried
Hi,
Before I put this is in as an enhancement request, I wanted to make sure
it doesn't already exist. I know you can define counters in a layout
function. Is there a mechanism to specify, say when defining a section
style, that certain counters get reset at the start of the section? If
Sven Hoexter wrote:
On Sun, Jul 15, 2007 at 12:08:13PM +0200, Peter Kümmel wrote:
Hi,
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove BugfixSignal, and
create the signal at runtime. But we then have to clean up
No. Why do you think new features cannot go into the stable series?
Maybe I am wrong, but in general the stable series do not allow format
changes. That is to say, 1.5.0 should be able to read all files
generated by 1.5.x.
Cheers,
Bo
Bo Peng wrote:
No. Why do you think new features cannot go into the stable series?
Maybe I am wrong, but in general the stable series do not allow format
changes. That is to say, 1.5.0 should be able to read all files
generated by 1.5.x.
I didn't state anything different. However, not all
Paul A. Rubin wrote:
Hi,
Before I put this is in as an enhancement request, I wanted to make
sure it doesn't already exist. I know you can define counters in a
layout function. Is there a mechanism to specify, say when defining a
section style, that certain counters get reset at the start
3. Rather TeX question - when typewriter font family is set, keywords are
no more bold (maybe it is not possible to typeset this font in bold,
dunno)
This is quite likely.
You have to use a typewriter font that actually provides bold faces.
listings manual advices LuxiMono fonts from CTAN.
On Sun, Jul 15, 2007 at 09:59:32AM -0400, Paul A. Rubin wrote:
Hi,
Before I put this is in as an enhancement request, I wanted to make sure it
doesn't already exist. I know you can define counters in a layout function.
Is there a mechanism to specify, say when defining a section
Pavel Sanda wrote:
listings manual advices LuxiMono fonts from CTAN. i've tried them and it
works well. i think this will be asked more often - what about little
update of our docs ?
Good idea. However,
+ If you don't have bold keywords when typewriter family of fonts is used,
+ you can
So how about something like
you are right. feel free to change it the way you like and commit it.
thanks
pavel
--- EmbeddedObjects.lyx 2007-07-03 12:55:59.0 +0200
+++ /trash/embed.lyx2007-07-15 18:04:12.0 +0200
@@ -28202,6 +28203,10 @@
\end_inset
is recognized and
Hi!
Is there any way for me to only apply one of the stages if the original
format number of the file being converted was under 249?
The problem with my current patch for bug 3613 is this:
Files from pre-249 are wrong, but post-249 don't have the problem. So my
new stage (277) should only
Jürgen Spitzmüller schrieb:
Abdelrazak Younes wrote:
As soon as do some cleanups (like I've done in my mvc branch)
back-porting will get more and more complicated. Backporting will
require additional work whereas developing feature and doing cleanup
directly in the stable branch will not.
Jürgen Spitzmüller schrieb:
1.5.2: T2=T1+2/3month, feature release, big patch and cleanup allowed
Probably yes. Depends on what remains from the 1.5.1 bugfixing and what bug
reports we have. Main focus is _always_ on stability. New features should
therefore be very well tested and
Dov Feldstern wrote:
Hi!
Attached find a patch for the last remaining problem with bug 3613. It's
a format change. The problem it solves is due to some missed cases way
back in format change 249.
I'm attaching example files which demonstrate the problem (and which
this patch fixes).
Dov Feldstern wrote:
Dov Feldstern wrote:
Hi!
Attached find a patch for the last remaining problem with bug 3613.
It's a format change. The problem it solves is due to some missed
cases way back in format change 249.
I'm attaching example files which demonstrate the problem (and which
Martin Vermeer wrote:
On Sun, Jul 15, 2007 at 09:59:32AM -0400, Paul A. Rubin wrote:
Hi,
Before I put this is in as an enhancement request, I wanted to make sure it
doesn't already exist. I know you can define counters in a layout function.
Is there a mechanism to specify, say when
Le 12 juil. 07 à 16:10, Richard Heck a écrit :
Go ahead and file the enhancement bug with a note pointing to this
thread. We can sort out the details later.
Done: bug #4022.
Mael.
Hi!
Here I will try to explain my understanding of the issues leading to
bugs 1820 and 3613. This is partly because I feel that it's important
that as many people as possible be aware of these, for future
development; partly in order to explain the patches I'm proposing for
these two bugs,
Hello LyXers,
I haven't found the time to follow the devel-list the last days, so somebody might have posted
something similar.
I'm awaiting the final LyX 1.5.0 release. I usually check bugzilla daily and think the only missing
problems are lyx2lyx bugs. Anders worked hard the last days with
Sven Hoexter wrote:
> Hi,
> while preparing a Debian package for the upcoming 1.5 release I've
> experienced a huge performance problem with 1.5rc1. Now I tried to find a
> reason and had to find out that the current trunk will segfault when I build
> it with the boost libs provided in the Debian
Bo Peng wrote:
This patch properly shut down what's needed to avoid the crashes.
OK?
I do not know this part of the code so you decide. Also, I did not use
multi-view when I had the crashes.
I suppose it depends on the machine and on when the statusbar timer was
timed out.
Anyway, this
On Sun, Jul 15, 2007 at 10:18:03AM +0200, Peter Kümmel wrote:
> Sven Hoexter wrote:
> > Hi,
> > while preparing a Debian package for the upcoming 1.5 release I've
> > experienced a huge performance problem with 1.5rc1. Now I tried to find a
> > reason and had to find out that the current trunk
Dov Feldstern wrote:
We create the 1.5.x branch *now*, but don't release yet.
That depends on how Juergen will manage the "stable" series. I
personally would like that we continue trunk development on the 1.5
series instead of opening a new 1.5.x branch. I would like to propose
that we
Sven Hoexter wrote:
> On Sun, Jul 15, 2007 at 10:18:03AM +0200, Peter Kümmel wrote:
>> Sven Hoexter wrote:
>>> Hi,
>>> while preparing a Debian package for the upcoming 1.5 release I've
>>> experienced a huge performance problem with 1.5rc1. Now I tried to find a
>>> reason and had to find out
On Sun, Jul 15, 2007 at 03:18:35AM +0300, Dov Feldstern wrote:
> Joost Verburg wrote:
> > Abdelrazak Younes wrote:
> >> Quite frankly, as there is no format change and that this needs some more
> >> testing, I'd prefer that you wait for 1.5.1 which will hopefully happen
> >> very soon. Just
On Sun, Jul 15, 2007 at 11:19:50AM +0200, Abdelrazak Younes wrote:
> Dov Feldstern wrote:
> > We create the 1.5.x branch *now*, but don't release yet.
>
> That depends on how Juergen will manage the "stable" series. I personally
> would like that we continue trunk development on the 1.5
Peter Kümmel wrote:
Maybe someone has an idea:
74 LyXView::LyXView(int id)
75 : work_area_(0),
76toolbars_(new Toolbars(*this)),
77autosave_timeout_(new Timeout(5000)),
78dialogs_(new Dialogs(*this)),
79
Abdelrazak Younes wrote:
> Dov Feldstern wrote:
> > We create the 1.5.x branch *now*, but don't release yet.
>
> That depends on how Juergen will manage the "stable" series. I
> personally would like that we continue trunk development on the 1.5
> series instead of opening a new 1.5.x branch. I
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Maybe someone has an idea:
74 LyXView::LyXView(int id)
75 : work_area_(0),
76 toolbars_(new Toolbars(*this)),
77 autosave_timeout_(new Timeout(5000)),
78 dialogs_(new Dialogs(*this)),
79
Abdelrazak Younes wrote:
> Hum, maybe the problem is in our side and not boost. This comment and
> code in frontends/Dialogs.cpp seems suspicious to me:
Yes, once again a static variable.
>
> // Note that static boost signals break some compilers, so this wrapper
> // initialises the signal
Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> Peter Kümmel wrote:
>>> Maybe someone has an idea:
>>>
>>> 74 LyXView::LyXView(int id)
>>> 75 : work_area_(0),
>>> 76 toolbars_(new Toolbars(*this)),
>>> 77 autosave_timeout_(new Timeout(5000)),
>>>
Abdelrazak Younes wrote:
> Hum, maybe the problem is in our side and not boost. This comment and
> code in frontends/Dialogs.cpp seems suspicious to me:
Yes, once again a static variable.
>
> // Note that static boost signals break some compilers, so this wrapper
> // initialises the signal
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Dov Feldstern wrote:
We create the 1.5.x branch *now*, but don't release yet.
That depends on how Juergen will manage the "stable" series. I
personally would like that we continue trunk development on the 1.5
series instead of opening a new
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove BugfixSignal, and
create the signal at runtime. But we then have to clean up correctly.
Your solution will only work with the first instance...
Abdelrazak Younes wrote:
> > I don't see the advantage of this. I'd rather do a 1.5.x branch and let
> > people do some more adventourous development (or new features) in trunk.
>
> I am thinking of GUI development. Dialogs, context menu, etc...
I don't see why this cannot happen in the current
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>>
>> Yes, this could be. We should simply NOT use the static solution.
>> Does attached patch work on Debian? If yes we could remove
>> BugfixSignal, and
>> create the signal at runtime. But we then have to clean up correctly.
>
> Your solution will
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>>
>> Yes, this could be. We should simply NOT use the static solution.
>> Does attached patch work on Debian? If yes we could remove
>> BugfixSignal, and
>> create the signal at runtime. But we then have to clean up correctly.
>
> Your solution will
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I don't see the advantage of this. I'd rather do a 1.5.x branch and let
people do some more adventourous development (or new features) in trunk.
I am thinking of GUI development. Dialogs, context menu, etc...
I don't see why this cannot
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we then have to clean up correctly.
Your solution
Hi,
I would love to have frontend support for \cancel{} which strikes out
parts in a formula as provided by cancel.sty. Looking at the svn it
seems to be pretty analog to e.g. implementing \sqrt{}. So I would like
to try this myself. I have c programming experience but no c++. Also it
looks as I
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>> Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we
Peter Kümmel wrote:
> Abdelrazak Younes wrote:
>> Peter Kümmel wrote:
>>> Abdelrazak Younes wrote:
Peter Kümmel wrote:
> Yes, this could be. We should simply NOT use the static solution.
> Does attached patch work on Debian? If yes we could remove
> BugfixSignal, and
> create
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we then have to clean up
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create
Abdelrazak Younes wrote:
> In the current scheme new feature will have to wait one year minimum
> before going to the public. In my proposed scheme new feature will be
> available every 3 month.
Why that?
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
In the current scheme new feature will have to wait one year minimum
before going to the public. In my proposed scheme new feature will be
available every 3 month.
Why that?
Why that what? You think that 1.6 will come in less than a year?
Abdelrazak Younes wrote:
The only solution is just to get rid of this BugfixSignal. Actually,
this hideSignal is not needed at all!
Something like the attached. I guess this signal was needed at some
point but not anymore.
Updated patch attached.
Abdel.
Index: frontends/Dialogs.cpp
Abdelrazak Younes wrote:
> > Why that?
>
> Why that what? You think that 1.6 will come in less than a year?
No. Why do you think new features cannot go into the stable series? As I've
outlined, I'm very open to backporting features that are tested and
straightforward (at least after 1.5.1).
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Why that?
Why that what? You think that 1.6 will come in less than a year?
No. Why do you think new features cannot go into the stable series? As I've
outlined, I'm very open to backporting features that are tested and
straightforward (at
Abdelrazak Younes wrote:
Hum, maybe the problem is in our side and not boost. This comment and
code in frontends/Dialogs.cpp seems suspicious to me:
// Note that static boost signals break some compilers, so this wrapper
// initialises the signal dynamically when it is first invoked.
Abdelrazak Younes wrote:
> As soon as do some cleanups (like I've done in my mvc branch)
> back-porting will get more and more complicated. Backporting will
> require additional work whereas developing feature and doing cleanup
> directly in the stable branch will not.
I see your point, but IMHO
Jürgen Spitzmüller wrote:
effort (but that's exactly the point where our opinions differ).
Exactly ;-)
Abdel.
Roger Mc Murtrie wrote:
Is there any relationship between this problem and Bug 4014, Comment 16
due to some changes in boost?
I don't think so.
Abdel.
On Sun, Jul 15, 2007 at 12:08:13PM +0200, Peter Kümmel wrote:
Hi,
> Yes, this could be. We should simply NOT use the static solution.
> Does attached patch work on Debian? If yes we could remove BugfixSignal, and
> create the signal at runtime. But we then have to clean up correctly.
Ok I tried
Hi,
Before I put this is in as an enhancement request, I wanted to make sure
it doesn't already exist. I know you can define counters in a layout
function. Is there a mechanism to specify, say when defining a section
style, that certain counters get reset at the start of the section? If
Sven Hoexter wrote:
On Sun, Jul 15, 2007 at 12:08:13PM +0200, Peter Kümmel wrote:
Hi,
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove BugfixSignal, and
create the signal at runtime. But we then have to clean up
No. Why do you think new features cannot go into the stable series?
Maybe I am wrong, but in general the stable series do not allow format
changes. That is to say, 1.5.0 should be able to read all files
generated by 1.5.x.
Cheers,
Bo
Bo Peng wrote:
> > No. Why do you think new features cannot go into the stable series?
>
> Maybe I am wrong, but in general the stable series do not allow format
> changes. That is to say, 1.5.0 should be able to read all files
> generated by 1.5.x.
I didn't state anything different. However, not
Paul A. Rubin wrote:
Hi,
Before I put this is in as an enhancement request, I wanted to make
sure it doesn't already exist. I know you can define counters in a
layout function. Is there a mechanism to specify, say when defining a
section style, that certain counters get reset at the start
>>> 3. Rather TeX question - when typewriter font family is set, keywords are
>>> no more bold (maybe it is not possible to typeset this font in bold,
>>> dunno)
>>
>> This is quite likely.
>
> You have to use a typewriter font that actually provides bold faces.
listings manual advices LuxiMono
On Sun, Jul 15, 2007 at 09:59:32AM -0400, Paul A. Rubin wrote:
> Hi,
>
> Before I put this is in as an enhancement request, I wanted to make sure it
> doesn't already exist. I know you can define counters in a layout function.
> Is there a mechanism to specify, say when defining a section
Pavel Sanda wrote:
> listings manual advices LuxiMono fonts from CTAN. i've tried them and it
> works well. i think this will be asked more often - what about little
> update of our docs ?
Good idea. However,
> + If you don't have bold keywords when typewriter family of fonts is used,
> + you
>So how about something like
you are right. feel free to change it the way you like and commit it.
thanks
pavel
--- EmbeddedObjects.lyx 2007-07-03 12:55:59.0 +0200
+++ /trash/embed.lyx2007-07-15 18:04:12.0 +0200
@@ -28202,6 +28203,10 @@
\end_inset
is recognized and
Hi!
Is there any way for me to only apply one of the stages if the original
format number of the file being converted was under 249?
The problem with my current patch for bug 3613 is this:
Files from pre-249 are wrong, but post-249 don't have the problem. So my
new stage (277) should only
1 - 100 of 108 matches
Mail list logo
