Re: [patch] aspell.C compile fix
shall I apply the fix? (including to aspell.C) Juergen.
[PATCH] centering float contents
http://bugzilla.lyx.org/show_bug.cgi?id=1290
This patch is on bugzilla for a while, but since there's no discussion I
thought I'd bring it up here.
As you know, LyX does not center (in general: align) float contents (figures,
tabulars) right, because \begin{center}...\end{center} is implemented as a
trivlist and adds some unwanted space.
LaTeXers usually recommend to use \centering inside floats to avoid this
problem:
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=vertspacefloat
However, \begin{centering}...\end{centering} is basically the same, but is
better markup.
The patch checks if we are inside a float/wrap and uses
\begin{centering}...\end{centering} etc. if true and
\begin{center}...\end{center} etc. if false.
There are still problems with aligning contents in tabular cells (especially
multiple pars in fixed width cells), but as discussed recently on this list,
this needs a different fix.
I think this issue must be fixed. What is your opinion on the patch?
Juergen.
Index: src/paragraph.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph.C,v
retrieving revision 1.318
diff -u -r1.318 paragraph.C
--- src/paragraph.C 9 Sep 2003 22:13:28 - 1.318
+++ src/paragraph.C 12 Sep 2003 06:06:07 -
@@ -687,6 +687,11 @@
// This could go to ParagraphParameters if we want to
+// \begin{center} and \begin{centering} are different
+// since the former is a trivlist and adds some vertical space
+// which is unwanted inside floats and tabular cells
+// therefor we have to use both. Same counts for
+// \begin{flushright} and \begin{raggedleft} etc.
int Paragraph::startTeXParParams(BufferParams const & bparams,
ostream & os, bool moving_arg) const
{
@@ -721,24 +726,39 @@
break;
case LYX_ALIGN_LEFT:
if (getParLanguage(bparams)->babel() != "hebrew") {
- os << "\\begin{flushleft}";
+ if (noTrivlistCentering())
+os << "\\begin{raggedright}";
+ else
+os << "\\begin{flushleft}";
column += 17;
} else {
- os << "\\begin{flushright}";
+ if (noTrivlistCentering())
+os << "\\begin{raggedleft}";
+ else
+os << "\\begin{flushright}";
column += 18;
}
break;
case LYX_ALIGN_RIGHT:
if (getParLanguage(bparams)->babel() != "hebrew") {
- os << "\\begin{flushright}";
+ if (noTrivlistCentering())
+os << "\\begin{raggedleft}";
+ else
+os << "\\begin{flushright}";
column += 18;
} else {
- os << "\\begin{flushleft}";
+ if (noTrivlistCentering())
+os << "\\begin{raggedright}";
+ else
+os << "\\begin{flushleft}";
column += 17;
}
break;
case LYX_ALIGN_CENTER:
- os << "\\begin{center}";
+ if (noTrivlistCentering())
+ os << "\\begin{centering}";
+ else
+ os << "\\begin{center}";
column += 14;
break;
}
@@ -777,24 +797,39 @@
break;
case LYX_ALIGN_LEFT:
if (getParLanguage(bparams)->babel() != "hebrew") {
- os << "\\end{flushleft}";
+ if (noTrivlistCentering())
+os << "\\par\\end{raggedright}";
+ else
+os << "\\par\\end{flushleft}";
column = 15;
} else {
- os << "\\end{flushright}";
+ if (noTrivlistCentering())
+os << "\\par\\end{raggedright}";
+ else
+os << "\\par\\end{flushright}";
column = 16;
}
break;
case LYX_ALIGN_RIGHT:
if (getParLanguage(bparams)->babel() != "hebrew") {
- os << "\\end{flushright}";
+ if (noTrivlistCentering())
+os << "\\par\\end{raggedleft}";
+ else
+os << "\\par\\end{flushright}";
column+= 16;
} else {
- os << "\\end{flushleft}";
+ if (noTrivlistCentering())
+os << "\\par\\end{raggedleft}";
+ else
+os << "\\par\\end{flushleft}";
column = 15;
}
break;
case LYX_ALIGN_CENTER:
- os << "\\end{center}";
+ if (noTrivlistCentering())
+ os << "\\par\\end{centering}";
+ else
+ os << "\\par\\end{center}";
column = 12;
break;
}
@@ -1329,6 +1364,15 @@
ParagraphParameters const & Paragraph::params() const
{
return pimpl_->params;
+}
+
+
+bool Paragraph::noTrivlistCentering() const
+{
+ if (pimpl_->inset_owner && pimpl_->inset_owner->owner())
+ return (pimpl_->inset_owner->owner()->lyxCode() == InsetOld::FLOAT_CODE
+ || pimpl_->inset_owner->owner()->lyxCode() == InsetOld::WRAP_CODE);
+ return false;
}
Index: src/paragraph.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph.h,v
retrieving revision 1.103
diff -u -r1.103 paragraph.h
--- src/paragraph.h 6 Sep 2003 18:38:01 - 1.103
+++ src/paragraph.h 12 Sep 2003 06:06:08 -
@@ -287,6 +287,14 @@
///
int stripLeadingSpaces();
+ /**
+ * In some environments, \centering or \begin{centering}...
+ * \end{centering} (which is the same) should be used rather
+ * than \begin{center}...\end{center} (which inserts some extra space)
+ * Return true if we are inside one of those
+ */
+ bool noTrivlistCentering() const;
+
/// return true if we allow multiple spaces
frenchb
Why do we have frenchb in lib/languages ? The Babel documentation says that it is obsolete.
Re: --with-included-strings
> We can do this for a while, until you have been able to test the > private inheritance stuff. But do you really expect private > inheritance to work better than forwarding? A bit perhaps. Definitely not much, maybe not even measurable. > The reason forwarding didn't work well is that stirngs are used all > over, and the complete type is needed as well. That won't change for > private inheritance. Indeed. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: --with-included-strings
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Sep 11, 2003 at 05:24:12PM +0200, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | On Thu, Sep 11, 2003 at 03:41:41PM +0200, Lars Gullik Bjønnes wrote:
>> >> Andre Poenitz <[EMAIL PROTECTED]> writes:
>> >>
>> >> | --with-included-string
>> >> | 283 ./frontends/qt2/ui/moc
>> >> | 569 ./frontends/qt2/ui
>> >>
>> >> Did you test this now? I had to make sevral small changes to get
>> >> with-included-string to work.
>> >
>> | Me too. But I don't have the patch at hand, just the results.
>>
>> Patch enclosed.
>
| Well, I would have liked a 'using std::string' in tex2lyx/*.C better
| than your explicit qualification but I can 'fix' that myself later.
I had to remove the using.. since in tex2lyx both basic_string and
lyxstirng are used... "using std::string" conflicted with "using
lyx::string"
>> >> And it must have been non-working for several days, so are anyone
>> >> really using lyxstring?
>> >
>> | Probably not too many...
>>
>> So your vote is to...?
>
| remove lyxstring.C.
So 3-0 now.
>
| In lyxstring.h write
>
| #include
>
| namespace lyx {
|
| using std::string;
>
| }
We can do this for a while, until you have been able to test the
private inheritance stuff. But do you really expect private
inheritance to work better than forwarding? The reason forwarding
didn't work well is that stirngs are used all over, and the complete
type is needed as well. That won't change for private inheritance.
| Drop STRCONV.
Certainly.
--
Lgb
Re: Towards LyX 1.3.3 (status update #2)
On Wed, Sep 10, 2003 at 06:30:35PM +0200, Jean-Marc Lasgouttes wrote: > Ronald Florence). The patch mathed.patch fixes this, but I have no > idea of the side effects on linux (I do not use xft). > > Could you have a look? Could it be that the fonts themsleves have Patch doesn't apply ... > wrong metrics? Maybe. john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: --with-included-strings
On Thu, Sep 11, 2003 at 05:24:12PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Thu, Sep 11, 2003 at 03:41:41PM +0200, Lars Gullik Bjønnes wrote:
> >> Andre Poenitz <[EMAIL PROTECTED]> writes:
> >>
> >> | --with-included-string
> >> | 283 ./frontends/qt2/ui/moc
> >> | 569 ./frontends/qt2/ui
> >>
> >> Did you test this now? I had to make sevral small changes to get
> >> with-included-string to work.
> >
> | Me too. But I don't have the patch at hand, just the results.
>
> Patch enclosed.
Well, I would have liked a 'using std::string' in tex2lyx/*.C better
than your explicit qualification but I can 'fix' that myself later.
> >> And it must have been non-working for several days, so are anyone
> >> really using lyxstring?
> >
> | Probably not too many...
>
> So your vote is to...?
remove lyxstring.C.
In lyxstring.h write
#include
namespace lyx {
using std::string;
}
Drop STRCONV.
Note that I'd like to keep that lyx::string 'wrapper' for a while to
be (a) able to play a bit with 'class lyx::string : private std::string
{};' and (b) to keep the change small.
I do not really expect 10%+ gains from the private inheritance but I'd
like to keep that option until we've seen hard figures. After that we
could completely remove lyxstring.h. If you did the 'big jump' at once,
I'd have to un-do most of your patch in my local tree for the playing
which is a complete waste of time for me.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: --with-included-strings
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Sep 11, 2003 at 03:41:41PM +0200, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> |--with-included-string
>> |283 ./frontends/qt2/ui/moc
>> |569 ./frontends/qt2/ui
>>
>> Did you test this now? I had to make sevral small changes to get
>> with-included-string to work.
>
| Me too. But I don't have the patch at hand, just the results.
Patch enclosed.
>> And it must have been non-working for several days, so are anyone
>> really using lyxstring?
>
| Probably not too many...
So your vote is to...?
? lyxstring.diff
Index: src/factory.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/factory.C,v
retrieving revision 1.54
diff -u -p -r1.54 factory.C
--- src/factory.C 9 Sep 2003 22:13:23 - 1.54
+++ src/factory.C 11 Sep 2003 15:22:52 -
@@ -144,7 +144,7 @@ InsetOld * createInset(FuncRequest const
case LFUN_TABULAR_INSERT:
if (!cmd.argument.empty()) {
- std::istringstream ss(cmd.argument);
+ std::istringstream ss(STRCONV(cmd.argument));
int r, c;
ss >> r >> c;
if (r <= 0) r = 2;
Index: src/lyxfind.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfind.C,v
retrieving revision 1.51
diff -u -p -r1.51 lyxfind.C
--- src/lyxfind.C 9 Sep 2003 22:13:25 - 1.51
+++ src/lyxfind.C 11 Sep 2003 15:22:52 -
@@ -193,7 +193,7 @@ int replace(BufferView * bv,
str2 = lowercase(text->selectionAsString(*bv->buffer(), false));
}
if (str1 != str2) {
- if (!find(bv, searchstr, fw, casesens, matchwrd) ||
+ if (!lyx::find::find(bv, searchstr, fw, casesens, matchwrd) ||
!replaceall) {
return 0;
}
@@ -213,7 +213,7 @@ int replace(BufferView * bv,
++replace_count;
}
if (!once)
- found = find(bv, searchstr, fw, casesens, matchwrd);
+ found = lyx::find::find(bv, searchstr, fw, casesens, matchwrd);
} while (!once && replaceall && found);
// FIXME: should be called via an LFUN
Index: src/frontends/xforms/Color.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/Color.C,v
retrieving revision 1.31
diff -u -p -r1.31 Color.C
--- src/frontends/xforms/Color.C 9 Sep 2003 17:25:30 - 1.31
+++ src/frontends/xforms/Color.C 11 Sep 2003 15:22:52 -
@@ -39,7 +39,7 @@ int const nohue = -1;
int hexstrToInt(string const & str)
{
int val = 0;
-istringstream is(str);
+istringstream is(STRCONV(str));
is >> std::setbase(16) >> val;
return val;
}
Index: src/support/lyxstring.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/lyxstring.C,v
retrieving revision 1.64
diff -u -p -r1.64 lyxstring.C
--- src/support/lyxstring.C 9 Sep 2003 17:25:35 - 1.64
+++ src/support/lyxstring.C 11 Sep 2003 15:22:53 -
@@ -16,6 +16,8 @@
#include "debug.h"
+#include
+
#include
#include
#include
@@ -60,8 +62,6 @@ using std::ostream;
// Lgb.
namespace lyx {
-
-using support::BOOST_ASSERT;
///
// The internal string representation
Index: src/tex2lyx/context.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/tex2lyx/context.C,v
retrieving revision 1.6
diff -u -p -r1.6 context.C
--- src/tex2lyx/context.C 9 Sep 2003 18:27:24 - 1.6
+++ src/tex2lyx/context.C 11 Sep 2003 15:22:53 -
@@ -138,7 +138,7 @@ void Context::check_end_deeper(ostream &
}
-void Context::dump(ostream & os, string const & desc) const
+void Context::dump(ostream & os, std::string const & desc) const
{
os << "\n" << desc <<" [";
if (need_layout)
Index: src/tex2lyx/math.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/tex2lyx/math.C,v
retrieving revision 1.10
diff -u -p -r1.10 math.C
--- src/tex2lyx/math.C 9 Sep 2003 18:27:24 - 1.10
+++ src/tex2lyx/math.C 11 Sep 2003 15:22:53 -
@@ -20,10 +20,9 @@ using std::cerr;
using std::endl;
using std::ostream;
-using std::string;
-bool is_math_env(string const & name)
+bool is_math_env(std::string const & name)
{
static char const * known_math_envs[] = { "equation", "equation*",
"eqnarray", "eqnarray*", "align", "align*", "gather", "gather*",
@@ -154,7 +153,7 @@ void parse_math(Parser & p, ostream & os
;
else if (t.cs() == "begin") {
- string const name = p.getArg('{', '}');
+ std::string const name = p.getArg('{', '}');
active_environments.push_back(name);
os << "\\begin{" << name << "}";
if (name == "tabular")
@@ -167,7 +166,7 @@ void parse_math(Parser & p, ostream & os
else if (t.cs() == "end") {
if (flags & FLAG_END) {
// eat environment name
-string const name = p.getArg('{', '}');
+std::string c
Re: --with-included-strings
On Thu, Sep 11, 2003 at 05:08:18PM +0200, Lars Gullik Bjønnes wrote: > My vote is to ditch lyx::string now. Amen. john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: --with-included-strings
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Andre Poenitz <[EMAIL PROTECTED]> writes: > | | --with-included-string | | 283 ./frontends/qt2/ui/moc | | 569 ./frontends/qt2/ui Ok, this is the results from my testing: | Build Time | Link Time | ls -l| size| du -s | std::string | 16m48.670s | 2m22.780s | 71923219 | 3239613 | 381364 | lyx::string | 15m21.480s | 2m24.820s | 68838301 | 2880900 | 367984 | - Numbers are pretty equal. Getting rid of lyxstring will make the codebase somewhat cleaner: STRCONV can go, several S.c_str() can go. And even when compiling with lyx::string, std::string is used in some palaces (and that cannot be avoided.) My vote is to ditch lyx::string now. -- Lgb
[patch] aspell.C compile fix
regards, Juergen. Index: src/aspell.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/aspell.C,v retrieving revision 1.7 diff -u -r1.7 aspell.C --- src/aspell.C 9 Sep 2003 22:13:22 - 1.7 +++ src/aspell.C 11 Sep 2003 14:42:05 - @@ -20,6 +20,8 @@ #include "aspell_local.h" #include "WordLangTuple.h" +#include + ASpell::ASpell(BufferParams const &, string const & lang) : els(0), spell_error_object(0)
Another trivial "make dist" problem
With this, I now have the automated builds working again. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92) Index: src/support/Makefile.am === RCS file: /cvs/lyx/lyx-devel/src/support/Makefile.am,v retrieving revision 1.66 diff -u -u -r1.66 Makefile.am --- src/support/Makefile.am 2003/09/10 23:06:18 1.66 +++ src/support/Makefile.am 2003/09/11 14:44:19 @@ -7,7 +7,8 @@ INCLUDES = -I$(srcdir)/../ $(BOOST_INCLUDES) EXTRA_DIST = path_defines.C.in lyxstring.C lyxstring.h \ -os_unix.C os_win32.C os_os2.C +os_unix.C os_win32.C os_os2.C gzstream.C gzstream.h \ +cow_ptr.h if USE_LYXSTRING LYXSTRING = lyxstring.C lyxstring.h
Re: Towards LyX 1.3.3 (status update #2)
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> I'd rather think your fonts are correct and the fonts we've Andre> seen so far are broken as we have this code The problem is that these are the same fonts, but Qt/X11 and Qt/Mac do not give the same result. This may be because the fonts are broken. JMarc
Re: Towards LyX 1.3.3 (status update #2)
On Wed, Sep 10, 2003 at 06:30:35PM +0200, Jean-Marc Lasgouttes wrote:
> > "John" == John Levon <[EMAIL PROTECTED]> writes:
>
> John> On Wed, Sep 10, 2003 at 05:55:27PM +0200, Jean-Marc Lasgouttes
> John> wrote:
> >> Ronald Florence also has a patch to make the display of \int or
> >> \prod correct with the latex-xft-fonts stuff and Qt/Mac. I'd really
> >> like to understand what is so special with those characters, but my
> >> experiments with ftmetric have been really unsuccesful until now.
>
> John> What's the story here ? I missed it
>
> Basically, with Qt/Mac and (I think) Qt/Win, the characters like \sum
> taken from cmex are displayed wrongly (see attached screenshot from
> Ronald Florence). The patch mathed.patch fixes this, but I have no
> idea of the side effects on linux (I do not use xft).
>
> Could you have a look? Could it be that the fonts themsleves have
> wrong metrics?
I'd rather think your fonts are correct and the fonts we've seen so far
are broken as we have this code
void MathSymbolInset::metrics(MetricsInfo & mi, Dimension & dim) const
{
[...]
mathed_string_dim(mi.base.font, sym_->draw, dim);
// correct height for broken cmex and wasy font
if (sym_->inset == "cmex" || sym_->inset == "wasy") {
h_ = 4 * dim.des / 5;
dim.asc += h_;
dim.des -= h_;
}
[...]
since day one or so...
This 'correction' does not seem necessary with your fonts anymore.
Andre'
Re: --with-included-strings
On Thu, Sep 11, 2003 at 03:41:41PM +0200, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | --with-included-string > | 283 ./frontends/qt2/ui/moc > | 569 ./frontends/qt2/ui > > Did you test this now? I had to make sevral small changes to get > with-included-string to work. Me too. But I don't have the patch at hand, just the results. > And it must have been non-working for several days, so are anyone > really using lyxstring? Probably not too many... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: --with-included-strings
Andre Poenitz <[EMAIL PROTECTED]> writes: | --with-included-string | 283 ./frontends/qt2/ui/moc | 569 ./frontends/qt2/ui Did you test this now? I had to make sevral small changes to get with-included-string to work. And it must have been non-working for several days, so are anyone really using lyxstring? -- Lgb
Re: --with-included-strings
Andre Poenitz <[EMAIL PROTECTED]> writes: | Can anybody reproduce this? I'll have a look. (would be nice if some other compilers than gcc was tested...) (a cygwin test perhaps?) | If so, this might be the time to drop lyxstring... Yes, please. -- Lgb
Re: Potential bug?
On Thu, Sep 11, 2003 at 01:17:12PM +0200, Michael Schmitt wrote:
> Hi,
>
> I was looking for a small code snippet that tells me how to use
> iterators in combination with erase (the latter makes the iterator invalid).
>
> When browsing through the LyX sources, I came across the following code:
>
>void PreviewLoader::Impl::remove(string const & latex_snippet)
>{
>...
>InProgressProcesses::iterator ipit = in_progress_.begin();
>InProgressProcesses::iterator ipend = in_progress_.end();
>
>std::for_each(ipit, ipend, EraseSnippet(latex_snippet));
>
>for (; ipit != ipend; ++ipit) {
>InProgressProcesses::iterator curr = ipit++;
>if (curr->second.snippets.empty())
>in_progress_.erase(curr);
>}
>}
>
> Question: Is the "for" statement correct? ipit seems to be increased
> twice with each iteration. Is this loop a safe way to cope with iterators?
Looks indeed strange... but Angus just went off hunting midges, so it
might take a while before you get a more educated answer on this one.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
--with-included-strings
Some results from my 'stats' 'log': Old values: edit() -> LFUN_EDIT 283 ./frontends/qt2/ui/moc 565 ./frontends/qt2/ui 246 ./frontends/qt2/moc 1283./frontends/qt2 93 ./frontends/gnome 44157 ./frontends/controllers 7414./frontends/xforms/forms 102028 ./frontends/xforms 159877 ./frontends 19005 ./graphics 2705./tex2lyx 14713 ./support 50741 ./insets 51682 ./mathed 431640 . [EMAIL PROTECTED]:/usr/src/lyx/lyx-build-debug/src > ls -la lyx -rwxr-xr-x1 poenitz users82959400 2003-05-10 19:05 lyx RSS 226M --with-included-string 283 ./frontends/qt2/ui/moc 569 ./frontends/qt2/ui 246 ./frontends/qt2/moc 1287./frontends/qt2 93 ./frontends/gnome 41659 ./frontends/controllers 5642./frontends/xforms/forms 93614 ./frontends/xforms 147668 ./frontends 16362 ./graphics 1616./tex2lyx 12210 ./support 48851 ./insets 45285 ./mathed 395901 . [EMAIL PROTECTED]:/usr/src/lyx/lyx-build-debug-incstr/src > -rwxr-xr-x1 poenitz users77503118 2003-05-11 02:38 lyx RSS 199M, link time 2:50 boost::format to lstrings.h 283 ./frontends/qt2/ui/moc 569 ./frontends/qt2/ui 246 ./frontends/qt2/moc 1287./frontends/qt2 93 ./frontends/gnome 41131 ./frontends/controllers 5642./frontends/xforms/forms 92838 ./frontends/xforms 146360 ./frontends 16350 ./graphics 1616./tex2lyx 12166 ./support 48338 ./insets 45281 ./mathed 390930 . RSS 195M, link time 2:38 Yesterday's values: lyx-build-debug: > du . | grep -v .deps | grep -v .libs 287 ./frontends/qt2/ui/moc 577 ./frontends/qt2/ui 250 ./frontends/qt2/moc 1311./frontends/qt2 93 ./frontends/gnome 35961 ./frontends/controllers 8099./frontends/xforms/forms 92831 ./frontends/xforms 139918 ./frontends 14461 ./graphics 8525./tex2lyx 14332 ./support 41126 ./insets 40326 ./mathed 373957 . -rwxr-xr-x1 poenitz users73062026 2003-09-11 00:24 lyx-xforms -rwxr-xr-x1 poenitz users 3194168 2003-09-11 01:21 lyx-xforms link RSS 181M, link time 2:39 lyx-build-debug-incstr: > du . | grep -v .deps | grep -v .libs 283 ./frontends/qt2/ui/moc 569 ./frontends/qt2/ui 246 ./frontends/qt2/moc 1287./frontends/qt2 93 ./frontends/gnome 35582 ./frontends/controllers 6263./frontends/xforms/forms 91292 ./frontends/xforms 138227 ./frontends 14737 ./graphics 3721./tex2lyx 13648 ./support 42923 ./insets 41252 ./mathed 368876 . ls -la lyx-xforms / stripped -rwxr-xr-x1 poenitz users72155254 2003-09-11 01:17 lyx-xforms -rwxr-xr-x1 poenitz users 4189080 2003-09-11 01:22 lyx-xforms link RSS 180M, link time 2m41.030s So this looks as if after Angus' recent #include cleanup there is not much difference between --with and --without-included-strings anymore. [Note that '--with' does not contain 5MB for tex2lyx which does not fully compile] Can anybody reproduce this? If so, this might be the time to drop lyxstring... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Potential bug?
Hi,
I was looking for a small code snippet that tells me how to use
iterators in combination with erase (the latter makes the iterator invalid).
When browsing through the LyX sources, I came across the following code:
void PreviewLoader::Impl::remove(string const & latex_snippet)
{
...
InProgressProcesses::iterator ipit = in_progress_.begin();
InProgressProcesses::iterator ipend = in_progress_.end();
std::for_each(ipit, ipend, EraseSnippet(latex_snippet));
for (; ipit != ipend; ++ipit) {
InProgressProcesses::iterator curr = ipit++;
if (curr->second.snippets.empty())
in_progress_.erase(curr);
}
}
Question: Is the "for" statement correct? ipit seems to be increased
twice with each iteration. Is this loop a safe way to cope with iterators?
Kind regards,
Michael
Re: counters
Andre Poenitz <[EMAIL PROTECTED]> writes: | Do we have already 'generic counters'? > | I.e. can I get 'Theorem 2.4' displayed within LyX? > >>From a quick glance it looks as some of the needed code is there but the | final bits are hard-coded... We are pretty close, but as you have discovered some bits are missing. -- Lgb
counters
Do we have already 'generic counters'? I.e. can I get 'Theorem 2.4' displayed within LyX? >From a quick glance it looks as some of the needed code is there but the final bits are hard-coded... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
