Jean-Marc Lasgouttes a écrit :
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> IMHO, this is because the code is not object oriented. In
Abdelrazak> this context docIterator is an advantage. When/if we move
Abdelrazak> to a truly object oriented way of dealing with insets I
Abdelrazak> believe that most of the its use will disappear.
dociterator is a nice way to pass context information to an inset
instead of having the inset cache this information.
Abdelrazak> Beside updating _all_ the counters of the document
Abdelrazak> (including inside insets!) because of one new paragraph
Abdelrazak> seems wrong to me.
You are right if you never plan to add counters inside floats. Think
caption inside a float inset. Think enumeration in a footnote in an
enumeration.
Sorry but I do not see why modifying an enum in one footnote should
impact a caption inside a float inset.
Beside, counters inside a float works fine with my patch which does not
remove functionalities.
IMHO, enumeration inside a footnote in an enumeration should not inherit
the counter context of its mother enumeration.
What would be more useful though is to see a profile so that we see
what the problem actually is. Rewriting everything just in case it
helps will not give us the solution.
Abdelrazak> This is something I don't understand, sorry. IMHO,
Abdelrazak> rewriting is a sane thing to do in any case if you want
Abdelrazak> more people to understand the code.
I was thinking of rewriting as a way to speed up code. I _really_
would like to see gprof output about this case. We cannot guess where
the problem is without seeing it.
So my word that it is slow and that my patch solves that slowness is not
enough? Do you want me to make a poll in the user list about lyx-1.4.x
under Windows?
And I can't make gprof works with mingw.
Now we can argue on whether we make the code more readable, but we
should not use speed as a justification until we can prove it.
My patch can prove it to any window user. This is a trust issue then.
I can
tell you that I did gprof optimization on this code and removed the
parts that were big offenders under linux. It is not as if the code
grew a life of its own.
I agree that this code is not very nice and is very fragile. This is
in part due to the difficulty of handling paragraph depth and inset
nesting.
Abdelrazak> There are really too much code of that sort in lyx. Please
Abdelrazak> find attached a patch that improve the situation
Abdelrazak> dramatically.
In what sense? Speed
Yes.
or legibility?
IMHO yes also.
Is it the use of
needsUpdateCounters (should maybe be needsCountersUpdate) that helps?
Yes.
Abdelrazak> The LABEL_ENUMERATE case optimization is not yet enabled
Abdelrazak> but is almost ready. Passing (Buffer const & buf) is not
Abdelrazak> nice from an OO point of view but this can be solved
Abdelrazak> later.
I still do not see what you gain versus passing a DocIterator.
For one thing I can use the function without having to create a
DocIterator artificially, hence less code.
Anyway, do what you want with the patch. I will maintain my own version
locally.
Abdel.
JMarc
