Guillaume Munch wrote:

> I submit it on the list to get your agreement on several fundamental
> changes which I kept, as you will see, as little intrusive as possible.

Wow, these are lots of changes. I am running out of time and will only 
comment on some.

> The sensitive changes (i.e. where I have been careful to make the
> simplest changes so as to not affect latex output) are indicated with *.
> 
> #1: Add math cell positions to TexRow. It mainly consists in new code
> that generalises the old one, and it is not output-related. (But this is
> where I had the most fun.)
> 
> *#2: Add a unique id to math insets. I also print this information in
> the DEVEL_VERSION in the status bar similarly to what is done currently
> for paragraphs. It is interesting that while the paragraph id is usually
> below 10000, this new math inset id immediately goes into the millions
> on opening an actual LyX document and it increases very quickly (which I
> suspect is due to updateMacros()).

Please measure memory consumption. I am a bit afraid that this increases 
memory usage a lot, since math insets contain very tiny bits of information, 
and you may need _lots_ of them even for simple formula.

Why do you need a new member variable at all? Why can't you just use the 
memory address? This would not consume memory and still be a unique id.

> *#3: Splitting otexstream into otexrowstream and otexstream.
> otexrowstream focuses on the line counting feature.

This is good IMHO.

> #4: Adding TexRow information on math latex output. WriteStream now uses
> the new otexrowstream instead of odocstream. (This should not be
> sensitive because the dangerous work has been done in #3.) This finishes
> implementing row tracking for math output.
> 
> #5: TexRow info in source panel and gotoCursor() for debugging. These
> are debugging features that are currently activated with Debug::LATEX in
> DEVEL_VERSION and appear in the source panel. Please, tell me if there
> are more appropriate conditions to enable these features. They will
> continue to be useful for debugging anything TexRow-related.
> 
> *#6: Remove a deep copy of MathData in lyx::write that interfered with
> TexRow. If anybody can explain to me the purpose of this antediluvian
> call to extractStrings, I am all ears.

Fortunately I can answer this question: extractStrings() exists to make the 
formulas better suitable for feeding them to external programs like computer 
algebra systems. It is also used for debug output (dump()) to make it more 
readable for humans.

> In the meanwhile, I wrote
> equivalent code in case it was actually useful.

The new code looks rather complicated to me. I think the old one should be 
kept. What I do not understand is why this code is executed at all for LaTeX 
output. I believe that it can even produce wrong PDF contents. Therefore, if 
LaTeX output is fixed to not call the free function write() at all, then 
extractStrings() can be kept and will not interfere.

> I noticed a major
> decrease of the math inset ids after this patch; hopefully this id is a
> new metrics that will allow us to observe further improvements to the
> implementation of maths.

I am not sure whether this is a good measure for mathed code quality. It is 
a central idea of mathed that a math inset is a self contained data class. 
If you assume that then it is not necessarily a problem if many copies are 
made.


Georg


Reply via email to