Uwe Stöhr wrote:
Besides this, tables work fine with g-brief2, see the latest attachment to
http://bugzilla.lyx.org/show_bug.cgi?id=4037
Irrelevant. This bug has to be fixed nevertheless, it's not bound to gbrief
only.
Jürgen
On Mon, 17 Sep 2007 22:27:22 -0500
Bo Peng [EMAIL PROTECTED] wrote:
On 9/17/07, Uwe Stöhr [EMAIL PROTECTED] wrote:
I would suggest (think I did) to completely leave Idx: off, and make the
appearance of the button distinctive. People are curious and will click
if they wonder what it
I need a little more information than your website seems to provide - simply
to work out which was the latest version for Win95 ...
http://www.lyx.org/download/ says, under heading Windows (9x/Me/2000/XP),
Starting with LyX 1.3.6, the Windows platform is supported officially by
the LyX team.
Martin Vermeer wrote:
Another alternative would be to introduce an Open/Closed state, which
can be toggled by right mouse, or from the menu for all insets together.
Closed means: only show Idx:, open: show part of content.
Or make index a _real_ collapsable and drop the dialog. This would have
Uwe Stöhr wrote:
So the correct fix is to drop the two g-brief layouts and add a routine
in lyx2lyx that converts files from g-brief to g-brief2. This is a file
format change so I would say wontfix for LyX 1.5.x.
Are you sure that everything done with gbrief can be reproduced 100% (I mean:
Abdelrazak Younes wrote:
That makes sense to me. Another advantage is that full unicode with
proper LyX binding is available
I think InsetLabel should go that road too...
even more InsetURL, which should have the CharStyle look IMO, since it is a
char style, basically (even though we
Abdelrazak Younes wrote:
Pavel Sanda wrote:
hello,
i'm trying to derive new kind of inset, which would be similar to
InsetBox, but i need it to be fixed-width (i mean really fixed, not
that after reaching .width the inset is magnified to wider text).
Why not adding a new option to InsetBox
Pavel Sanda wrote:
hello,
i'm trying to derive new kind of inset, which would be similar to
InsetBox, but i need it to be fixed-width (i mean really fixed, not
that after reaching .width the inset is magnified to wider text).
Why not adding a new option to InsetBox instead?
is this somehow
Jürgen Spitzmüller wrote:
Martin Vermeer wrote:
Another alternative would be to introduce an Open/Closed state, which
can be toggled by right mouse, or from the menu for all insets together.
Closed means: only show Idx:, open: show part of content.
Or make index a _real_ collapsable and drop
Pavel Sanda wrote:
hello,
i'm trying to derive new kind of inset, which would be similar to
InsetBox, but i need it to be fixed-width (i mean really fixed, not
that after reaching .width the inset is magnified to wider text).
I tried to test 1.4 and 1.5 to get a sense on how InsetBox should
Abdelrazak Younes wrote:
I tried to test 1.4 and 1.5 to get a sense on how InsetBox should behave
but I get painting and size problems in both. Could someone explain me
how this should behave on screen?
This thing looks really broken...
It is broken:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I tried to test 1.4 and 1.5 to get a sense on how InsetBox should behave
but I get painting and size problems in both. Could someone explain me
how this should behave on screen?
This thing looks really broken...
It is broken:
Abdelrazak Younes wrote:
So the fix would be to revert your change now that the wide() thing is
gone, wouldn't it?
I guess so, yes. We'll have to double-check that bug 2884 and bug 3437 remein
fixed, though.
Jürgen
Pavel Sanda [EMAIL PROTECTED] writes:
hello,
i'm trying to derive new kind of inset, which would be similar to
InsetBox, but i need it to be fixed-width (i mean really fixed, not
that after reaching .width the inset is magnified to wider text).
Isn't it already supposed to work like that?
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
So the fix would be to revert your change now that the wide() thing is
gone, wouldn't it?
I guess so, yes. We'll have to double-check that bug 2884 and bug 3437 remein
fixed, though.
Yep, I verified that... it will be even better fixed:
Hi all,
could somebody please confirm this as it was discussed on the list
already. I thought a consensus was reached to fix the width of Figure
floats to the display maximum.
http://bugzilla.lyx.org/show_bug.cgi?id=4002
Aside from wasting time on redraws if the figure is
Abdelrazak Younes wrote:
Yep, I verified that... it will be even better fixed: the inner inset
will resize nicely inside.
Will commit once I'd done some more testing...
Cool. One more hack is gone.
Jürgen
Darren Freeman wrote:
Hi all,
could somebody please confirm this as it was discussed on the list
already. I thought a consensus was reached to fix the width of Figure
floats to the display maximum.
http://bugzilla.lyx.org/show_bug.cgi?id=4002
This is fixed in trunk already. Not easily
Both tex and pdflatex have an option -file-line-error that produces error
messages in a style that isn't known to LyX so far and thus isn't parsed
correctly.* It seems that some distributions have turned that option on by
default. As a consequence, LyX doesn't report any error messages when
On Tuesday 18 September 2007 09:33:02 Jürgen Spitzmüller wrote:
If there are no objections, I'd like to put this in branch and trunk.
Jürgen
* from the tex man page:
-file-line-error: Print error messages in the form file:line:error which
is similar to the way many compilers format them.
I
Martin Vermeer wrote:
OK, the attached. Wasn't too hard, but I couldn't really spare the time.
Seems to work.
I do not want to press you into spending more time that you don't have, but
unfortunately there is still a problem AFAICS. Maybe somebody else can
finish this?
Index:
On Tue, 18 Sep 2007 08:41:14 +0200
[EMAIL PROTECTED] (Jürgen Spitzmüller) wrote:
Abdelrazak Younes wrote:
That makes sense to me. Another advantage is that full unicode with
proper LyX binding is available
I think InsetLabel should go that road too...
even more InsetURL, which
Jean-Marc Lasgouttes wrote:
Pavel Sanda [EMAIL PROTECTED] writes:
hello,
i'm trying to derive new kind of inset, which would be similar to
InsetBox, but i need it to be fixed-width (i mean really fixed, not
that after reaching .width the inset is magnified to wider text).
Isn't it already
On Tue, 2007-09-18 at 10:32 +0200, Abdelrazak Younes wrote:
Darren Freeman wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=4002
This is fixed in trunk already. Not easily backportable unfortunately.
Can a different fix be applied to branch? Surely this is a simple
change. The inset knows not
Jürgen Spitzmüller schrieb:
...general, please tell me if the regex could be improved. The message style we
are looking for is:
filename.tex:line nr.: error message
I did not test it, but i would suggest this regular expression:
+ static regex file_line_error([^:]+:[0-9]+: (.+));
and
S J Collins wrote:
I need a little more information than your website seems to provide - simply
to work out which was the latest version for Win95 ...
I don't think there is any native version that works with Win95. The
best option would be to try Cygwin.
Joost
Darren Freeman wrote:
On Tue, 2007-09-18 at 10:32 +0200, Abdelrazak Younes wrote:
Darren Freeman wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=4002
This is fixed in trunk already. Not easily backportable unfortunately.
Can a different fix be applied to branch? Surely this is a simple
Bernhard Roider wrote:
I did not test it, but i would suggest this regular expression:
+ static regex file_line_error([^:]+:[0-9]+: (.+));
I'm not sure. We have to be careful that no other construct matches this
regex. My version checks for the dot, which should always be present in the
- Go to Preferences-Converters
- Select a converter, say LaTeX (plain) - DVI
- Modify this converter
- Hit the Change button
= CRASH.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47003240016464 (LWP 19945)]
0x2abfcacbdba8 in std::basic_stringchar,
Are you sure that everything done with gbrief can be reproduced 100% (I mean:
100%) with gbrief2?
Yes as far as I know.
How about letters that use ERT commands that have been
dropped in gbrief2?
As far as I know there are no dropped commands. The only one I could found id the command \BTX
Abdelrazak Younes [EMAIL PROTECTED] writes:
Isn't it already supposed to work like that?
This is now working like that.
Very good.
JMarc
Uwe Stöhr wrote:
Are you sure that everything done with gbrief can be reproduced 100% (I
mean: 100%) with gbrief2?
Yes as far as I know.
As far as I know is not enough.
How about letters that use ERT commands that have been
dropped in gbrief2?
As far as I know there are no
This is now working like that.
thank you Abdel :)
i'd like to ask one question more.
first my intenstion: i'd like to have one inset C
containing two derivates of insetbox A,B. C is not
supposed to do anything else than provide these two boxes
and have one special settings dialog on mouse
As far as I know there are no dropped commands.
What about \Telefon, for instance?
\Telefon has not been dropped, it was replaced by \TelephoneRowA. That's what I meant should be
converted when we switch from g-brief to g-brief2.
How about letters that include style files that rely on
i'll investigate...
-Original Message-
From: Jürgen Spitzmüller [mailto:[EMAIL PROTECTED]
Sent: Tue 9/18/07 11:50
To: LyX Devel
Subject: crash in trunk (preferences-converters)
- Go to Preferences-Converters
- Select a converter, say LaTeX (plain) - DVI
- Modify this converter
- Hit
Jürgen Spitzmüller schrieb:
Bernhard Roider wrote:
I did not test it, but i would suggest this regular expression:
+ static regex file_line_error([^:]+:[0-9]+: (.+));
I'm not sure. We have to be careful that no other construct matches this
regex. My version checks for the dot, which
Hi everyone,
I hope this is the right place to send feature requests. I have been
using LyX for years and am very happy with it!
It would be nice if you considered implementing the possibility of
cross-referencing to sections etc without the need of inserting ugly
labels - the use of labels
Pavel Sanda wrote:
This is now working like that.
thank you Abdel :)
i'd like to ask one question more.
first my intenstion: i'd like to have one inset C
containing two derivates of insetbox A,B. C is not
supposed to do anything else than provide these two boxes
and have one special
Darren Freeman wrote:
On Tue, 2007-09-18 at 10:32 +0200, Abdelrazak Younes wrote:
Darren Freeman wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=4002
This is fixed in trunk already. Not easily backportable unfortunately.
Can a different fix be applied to branch? Surely this is a simple
Uwe Stöhr wrote:
As far as I know there are no dropped commands.
What about \Telefon, for instance?
\Telefon has not been dropped, it was replaced by \TelephoneRowA. That's
what I meant should be converted when we switch from g-brief to g-brief2.
And if it's used as ERT or redefined
Bernhard Roider wrote:
i am not familiar with the possible filenames, thus the question: do all
kinds of filenames that can appear in that output have an extension and
does that extension never contain digits?
As far as I understand it, yes. Basically, this should be *.tex files (and
probably
Abdelrazak Younes wrote:
And here is a patch that improves the situation WRT InsetBox.
Où?
Jürgen
Abdelrazak Younes wrote:
Darren Freeman wrote:
On Tue, 2007-09-18 at 10:32 +0200, Abdelrazak Younes wrote:
Darren Freeman wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=4002
This is fixed in trunk already. Not easily backportable unfortunately.
Can a different fix be applied to branch?
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
And here is a patch that improves the situation WRT InsetBox.
Où?
Ici :-)
Abdel.
Index: insets/InsetBox.cpp
===
--- insets/InsetBox.cpp (revision 20318)
+++
Well, thanks to Richard we have the possibility to build custom flex
insets for this now, right? Look Ma, no C++!
All that's left then is adding the lyx2lyx code to convert the old
insets to this.
Any takers?
Not me. I do not know what is a flex inset.
Bo
Missing #include algorithm. Fix committed.
I probably should reconfigure --without-pch to chatch this kind of
errors.
You should. I have fixed at least five such instances.
Bo
All that's left then is adding the lyx2lyx code to convert the old
insets to this.
BTW, giving different insets different size/color/shape makes sense to me.
Bo
On Tue, 18 Sep 2007, Yann Disser wrote:
It would be nice if you considered implementing the possibility of
cross-referencing to sections etc without the need of inserting ugly
labels - the use of labels should in my opinion be reduced to an
absolute minimum. My works are often full of labels
On Tue, 18 Sep 2007 10:58:46 +0200
Georg Baum [EMAIL PROTECTED] wrote:
Martin Vermeer wrote:
OK, the attached. Wasn't too hard, but I couldn't really spare the time.
Seems to work.
I do not want to press you into spending more time that you don't have, but
unfortunately there is still
On Tuesday 18 September 2007 15:38:51 Bo Peng wrote:
You should. I have fixed at least five such instances.
Using gcc 4.1.2 and with pch disabled I don't see this.
I am not saying there is not a bug, I am not seeing with pch disabled.
Bo
--
José Abílio
Abdelrazak Younes wrote:
Ici :-)
This looks good. I only had time for a very cursory test, though. If you have
tested it well and feel confident with it, you can commit it.
Jürgen
In any event, flex insets are what used to be charstyles, only now it's
possible to make them collapsable as well as inline. So you can do
something like this:
InsetLayout Custom:Label
LyXTypecustom
LatexNamelabel
LatexTypecommand
Decorationclassic
Bo Peng wrote:
Well, thanks to Richard we have the possibility to build custom flex
insets for this now, right? Look Ma, no C++!
All that's left then is adding the lyx2lyx code to convert the old
insets to this.
Any takers?
Not me. I do not know what is a flex inset.
Well, I
Bo Peng wrote:
In any event, flex insets are what used to be charstyles, only now it's
possible to make them collapsable as well as inline. So you can do
something like this:
InsetLayout Custom:Label
LyXTypecustom
LatexNamelabel
LatexTypecommand
Decorationclassic
[EMAIL PROTECTED] wrote:
On Tue, 18 Sep 2007, Yann Disser wrote:
It would be nice if you considered implementing the possibility of
cross-referencing to sections etc without the need of inserting ugly
labels - the use of labels should in my opinion be reduced to an
absolute minimum. My works
Uwe Stöhr wrote:
Provided I have administration rights or at least the right to copy and
change
the file in my home texmf.
You don't need admin rights as the files are already in the global texmf
folder and you can copy them to your private one.
Given that I'm allowed to do this (see
Uwe Stöhr wrote:
want. When you have installed g-brief on your LaTeX-system you
automatically also have installed g-brief2.
Provided I have administration rights or at least the right to copy and change
the file in my home texmf.
You don't need admin rights as the files are already in the
Martin Vermeer wrote:
I just committed a fix to all reported problems.
Thanks. I hope it did not take too much time!
Georg
Am Dienstag, 18. September 2007 schrieb [EMAIL PROTECTED]:
URL: http://www.lyx.org/trac/changeset/20347
Log:
Fix bug 4223: minor change to amsmaths.inc, per Georg.
I asked not to put this to branch for the time being, since Paul Rubin is
working on a complete rewrite, and this will interfere
Jürgen Spitzmüller wrote:
I asked not to put this to branch for the time being, since Paul Rubin is
working on a complete rewrite, and this will interfere with his changes.
Please revert. Paul already included this in his new version.
Never mind. I see you already did.
Jürgen
Are these LFUNs still desirable in their present form? I have
specifically in mind LFUN_FONT_CODE and LFUN_FONT_NOUN, which have
really been replaced with logical character styles.
Richard
--
==
Richard G Heck, Jr
Professor of
On Tue, Sep 18, 2007 at 01:42:47PM -0400, Richard Heck wrote:
Are these LFUNs still desirable in their present form? I have
specifically in mind LFUN_FONT_CODE and LFUN_FONT_NOUN, which have
really been replaced with logical character styles.
Richard
Hmmm yes... actually I would like to
What's the status of this? Are we still discussing implementation, or
can this go in? If the latter, I can commit it later.
Richard
Tommaso Cucinotta wrote:
Abdelrazak Younes ha scritto:
Tommaso Cucinotta wrote:
Why don't you just start from embedding the patch
I sent you for the LFUN +
On 9/18/07, Richard Heck [EMAIL PROTECTED] wrote:
Bo Peng wrote:
Well, thanks to Richard we have the possibility to build custom flex
insets for this now, right? Look Ma, no C++!
All that's left then is adding the lyx2lyx code to convert the old
insets to this.
Any takers?
Not
On Tue, Sep 18, 2007 at 01:17:07PM +0200, Pavel Sanda wrote:
This is now working like that.
thank you Abdel :)
i'd like to ask one question more.
first my intenstion: i'd like to have one inset C
containing two derivates of insetbox A,B. C is not
supposed to do anything else than
On Tue, Sep 18, 2007 at 07:40:35PM +0200, Alfredo Braunstein wrote:
On 9/18/07, Richard Heck [EMAIL PROTECTED] wrote:
Bo Peng wrote:
Well, thanks to Richard we have the possibility to build custom flex
insets for this now, right? Look Ma, no C++!
All that's left then is adding the
Richard Heck wrote:
What's the status of this? Are we still discussing implementation, or
can this go in? If the latter, I can commit it later.
I am personally OK with it, at least on the code side. Concerning the
binding, I'd prefer to make master-preview the default (using pdflatex).
But
Andre Poenitz wrote:
On Tue, Sep 18, 2007 at 07:40:35PM +0200, Alfredo Braunstein wrote:
This flex name is sort of uninformative. What about calling them
soft insets (as in soft-coded vs. hard-coded)?
It's as uninformative.
Martin changed it from InsetCharStyle because they'd become
Andre Poenitz wrote:
On Tue, Sep 18, 2007 at 01:17:07PM +0200, Pavel Sanda wrote:
This is now working like that.
thank you Abdel :)
i'd like to ask one question more.
first my intenstion: i'd like to have one inset C
containing two derivates of insetbox A,B. C is not
supposed to do anything
Martin Vermeer wrote:
On Tue, Sep 18, 2007 at 01:42:47PM -0400, Richard Heck wrote:
Are these LFUNs still desirable in their present form? I have
specifically in mind LFUN_FONT_CODE and LFUN_FONT_NOUN, which have
really been replaced with logical character styles.
Hmmm yes... actually
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Ici :-)
This looks good. I only had time for a very cursory test, though. If you have
tested it well and feel confident with it, you can commit it.
Yes I feel confident about it. Committed.
Abdel.
Andre Poenitz wrote:
Without too much hackery I think InsetTabular is the only choice.
this sounds like a contradiction in terms to me...
As I said: InsetTabular might be the best start. But it's not easy this
way either.
perhaps start with writing an InsetGrid class and then have
Jürgen Spitzmüller schrieb:
Bernhard Roider wrote:
i am not familiar with the possible filenames, thus the question: do all
kinds of filenames that can appear in that output have an extension and
does that extension never contain digits?
As far as I understand it, yes. Basically, this should
Without too much hackery I think InsetTabular is the only choice.
to be frank, i already escaped from tabular code, after that started playing
with insetbox :)
i though about insetbox too - one would need to
-forbid editing inside C
This migth be possible.
-make the cursor move
On Tue, Sep 18, 2007 at 08:49:44PM +0200, Edwin Leuven wrote:
Andre Poenitz wrote:
Without too much hackery I think InsetTabular is the only choice.
this sounds like a contradiction in terms to me...
It will be ugly as heel, but everything else is probably worse.
As I said: InsetTabular
Edwin Leuven wrote:
Andre Poenitz wrote:
Without too much hackery I think InsetTabular is the only choice.
this sounds like a contradiction in terms to me...
As I said: InsetTabular might be the best start. But it's not easy this
way either.
perhaps start with writing an InsetGrid class
On Tuesday 18 September 2007 19:01:48 Martin Vermeer wrote:
Providing the corresponding lyx2lyx entry is going to be interesting.
But then we need the inset in inset case that André mentioned. After it is
possible to have word in noun and emphasised right now and we should
accommodate for
Andre Poenitz wrote:
perhaps start with writing an InsetGrid class and then have InsetTabular
derive from this?
NestInset ;-}
isn't there something like that in mathed?
I think we should ponder the everything is an inset - also paragraphs
are insets idea next time we are sufficiently
Hi,
I have been busy and did not had much to develop in LyX but here are
some of
my thoughts on the subject of compression.
I don't care so much if we drop the feature of reading compress files
with
lyx as long as the program deals with lyx.gz files. This should satisfy
On Tue, Sep 18, 2007 at 02:26:32PM -0400, Richard Heck wrote:
Andre Poenitz wrote:
On Tue, Sep 18, 2007 at 07:40:35PM +0200, Alfredo Braunstein wrote:
This flex name is sort of uninformative. What about calling them
soft insets (as in soft-coded vs. hard-coded)?
It's as
On Tuesday 18 September 2007 21:20:42 José Matos wrote:
Hi,
I have been busy and did not had much to develop in LyX but here are
some
of my thoughts on the subject of compression.
I don't care so much if we drop the feature of reading compress files
with
lyx as long as the
I don't care so much if we drop the feature of reading compress files
with
lyx as long as the program deals with lyx.gz files.
I agree that we can drop the compression feature as long as lyx2lyx
can decompress compressed files so that lyx can read it. As for the
embedding feature, the
On Tue, Sep 18, 2007 at 08:57:18PM +0100, José Matos wrote:
On Tuesday 18 September 2007 19:01:48 Martin Vermeer wrote:
Providing the corresponding lyx2lyx entry is going to be interesting.
But then we need the inset in inset case that André mentioned. After it is
possible to have word
If we want a different suffix for embedded lyx files why not to call them
.elyx?
I am not in favor of a separate file extension partly because of the
extra work (document, .cpp etc). If it is decided to use one, I would
prefer .lyz. 'z' is after 'x', it means 'compression', and '.lyz'
actually
Abdelrazak Younes [EMAIL PROTECTED] writes:
I am personally OK with it, at least on the code side. Concerning the
binding, I'd prefer to make master-preview the default (using
pdflatex). But this is another story.
I think it can go in now. Juergen, you could consider it for branch
too (just a
On Tue, Sep 18, 2007 at 09:55:05PM +0200, Edwin Leuven wrote:
Andre Poenitz wrote:
perhaps start with writing an InsetGrid class and then have InsetTabular
derive from this?
NestInset ;-}
isn't there something like that in mathed?
Sort of. MathArray is basically the equivalent to a
On Tue, Sep 18, 2007 at 10:55:51PM +0300, Martin Vermeer wrote:
On Tue, Sep 18, 2007 at 02:26:32PM -0400, Richard Heck wrote:
Andre Poenitz wrote:
On Tue, Sep 18, 2007 at 07:40:35PM +0200, Alfredo Braunstein wrote:
This flex name is sort of uninformative. What about calling them
soft
Is DocBook anywhere in active use?
Andre'
On Tuesday 18 September 2007 21:39:57 Martin Vermeer wrote:
Cannot be (easily) done with
insets. I would call that a feature: you shouldn't _want_ to do that ;-)
There is no good reason for not having insets inside inside insets. It is an
artificial limitation and it should be lifted. That
On Tue, Sep 18, 2007 at 10:12:43PM +0100, José Matos wrote:
On Tuesday 18 September 2007 21:39:57 Martin Vermeer wrote:
Cannot be (easily) done with
insets. I would call that a feature: you shouldn't _want_ to do that ;-)
There is no good reason for not having insets inside inside
On Tue, Sep 18, 2007 at 08:57:18PM +0100, José Matos wrote:
On Tuesday 18 September 2007 19:01:48 Martin Vermeer wrote:
Providing the corresponding lyx2lyx entry is going to be interesting.
But then we need the inset in inset case that André mentioned. After it is
The attached does this experimentally. It looks good... what we lose is
the possibility to get the previous word automatically into the index
inset. But I suspect there's a trick even for that if we go this way.
The question is, do we?
- Martin
(Some other rough edges still. It's the idea that
On Tue, Sep 18, 2007 at 10:53:51PM +0200, Andre Poenitz wrote:
On Tue, Sep 18, 2007 at 10:55:51PM +0300, Martin Vermeer wrote:
On Tue, Sep 18, 2007 at 02:26:32PM -0400, Richard Heck wrote:
Andre Poenitz wrote:
On Tue, Sep 18, 2007 at 07:40:35PM +0200, Alfredo Braunstein wrote:
On Tuesday 18 September 2007 22:24:32 Martin Vermeer wrote:
But you can! Just not half-way inside. It's not an artificial
limitation. In HTML you can do it, but it is frowned upon, rightly.
This is about logical mark-up. Where would you want to emphasize a
passage that includes only half the
Little puzzle for you:
What belongs together?
Configurations:
(A) current svn, --enable-pch
(B) current svn, --disable-pch
Compile times/size of build tree part frontend/qt4:
(1) real 7m35s user 6m25s sys 0m23s58.5 MB
(2) real 6m12s user 5m12s sys 0m19s19.9 MB
Solution:
On 9/18/07, Martin Vermeer [EMAIL PROTECTED] wrote:
Actually I toyed with the name 'soft', but wasn't sure. Then I asked if
anybody had a better idea than 'flex'. Nobody responded.
Okokok you're right ;-) Just for the records, when that happened, I
didn't know what was it about, actually :-/
Possible conclusions: Precompiled headers are a waste of time and space.
22% increase on compile times, ~300% increase on disk space.
Could somebody please try the same test with a different compiler?
I tried a while ago with gcc 3.4 on linux. Autotools' pch did not show
any advantage in
Hi all,
I'm just musing about possible causes for the unbearable slowness that
often befalls LyX and then mysteriously clears with a resize-maximise
cycle. I now realise there are multiple levels of slowness and multiple
cycles of the resize-maximise will restore speed in increments!
With lyx
On Tue, 2007-09-18 at 20:32 +0200, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Ici :-)
This looks good. I only had time for a very cursory test, though. If you
have
tested it well and feel confident with it, you can commit it.
Yes I feel confident
On Tue, Sep 18, 2007 at 10:42:19PM +0100, José Matos wrote:
On Tuesday 18 September 2007 22:24:32 Martin Vermeer wrote:
But you can! Just not half-way inside. It's not an artificial
limitation. In HTML you can do it, but it is frowned upon, rightly.
This is about logical mark-up. Where
1 - 100 of 200 matches
Mail list logo
