Lars Gullik Bjønnes wrote:
> We really should make a decision on how we want our naming to be.
Yes. I prefer CamelCase, but am fine with whatever we choose. Please make a
decision and document it in Code_Rules, discussing this again and again is
really tiresome.
> CamelCase or stl/boost style.
>
> At least we should not use different style for the same kind of
> entities. (Not really related to this patch though)
That is what I tried (but did not use ALL_CAPS because we have a rule
against it).
> Index: src/insets/ChangeLog
> ===================================================================
> --- src/insets/ChangeLog (Revision 14275)
> +++ src/insets/ChangeLog (Revision 14278)
> @@ -799,6 +799,10 @@
> * insettabular.[Ch] (string2params): Don't pretend to return the
> active cell anymore and simplify keyword parsing.
>
> +2004-11-11 Edwin Leuven
> +
> + * insettabular.C (getStatus, tabularFeatures): handle booktabs feature
> +
> 2004-11-10 Jean-Marc Lasgouttes
> <[EMAIL PROTECTED]>
>
> * insetlatexaccent.h (isLetter): implement, so that word selection
>
> Is this info now out dated?
No, it still decsribes a chaneg wrt trunk.
> And strictly speaking we are not using the ChangeLog more anyway...
> (Handled at commit time I guess.)
You remember when the booktabs branch started? End of 2004 (still ChangeLog
time). Should I remove those entries? I don't think so, because they are
not captured by commit logs.
> Index: src/tabular.C
> ===================================================================
> --- src/tabular.C (Revision 14275)
> +++ src/tabular.C (Revision 14278)
> @@ -64,6 +64,8 @@ using std::strlen;
> namespace {
>
> int const WIDTH_OF_LINE = 5;
> +int const default_line_space = 10;
>
> Hmm.. is this the same as the one in the other file?
Yes.
> (In insettabular.C)
> If so we should perhaps find a way so that we only need one of them?
I thought about that, but did not want to put it in a header because it is
an implementation detail. IMO the split of the tabular code between
tabular.C and insettabular.C is artificial and all should be moved to
insettabular.C eventually, so I prefer this solution that will then be
automatically merged.
What do you think?
> So I have looked through the patch and saw nothing wrong with it. I
> havent compiled or tested it though.
>
> Good work.
This goes mainly to Edwin and Jürgen, they did a great part of it.
Georg
