Re: Summary (was Re: asserts and pagebreaks)


Subject: Re: Summary (was Re: asserts and pagebreaks)
From: Jesper Skov (jskov@redhat.com)
Date: Fri May 26 2000 - 18:44:58 CDT


>>>>> "Mike" == Mike Nordell <tamlin@algonet.se> writes:

Mike> Jesper Skov wrote: A run should IMO *only* know about itself,
Mike> its position on the fp_Line, its DocPos wrt the block and a few
Mike> other things. It should know nothing about other runs (in a
Mike> perfect world).
>> But as far as I can tell, you cannot achieve the desired semantics
>> (in the current design anyway) without the Runs being able to tell
>> either that you can expect to get a hit next time, or that you are
>> past what you are looking for.

Mike> Shouldn't that be the job of the run-manager?

Run manager? The BlockLayout?

Mike> What's saying that the current design is correct? I'm not saying
Mike> it's incorrect, I don't know it enough to be the judge of that,
Mike> but there might be a slim chance that it is.

That was my (somewhat muddled) point with the above reference to the
current design.

FWIW I've reimplemented the functionality from scratch with all the
decisions being made in the BlockLayout loop. An added bonus is that
it's quite a bit more efficient. I still have to sort out the EOL
case: I know what needs to be done, I just need to determine when to
do what, and my brain's nearing caffeine depletion real fast now, so
it'll have to wait till tomorrow.

Oh, and I'll document it to death, including listing (asserting) the
assumptions and what cases the code is expected to handle. If the
requirements for the function ever changes it should make it a bit
easier to adjust the code.

And a final point, Justin Bradford mentioned using invisible Runs to
enclose Runs of a field. That should also work with the new code since
it makes only a simple assumption about where to find Runs that can
contain the point (the assumption being that there must be at least
one such Run on a line).

Anyhu, having praised my code to death now, I'm sure Murphy will see
to a complete code (or harddisk) breakdown tomorrow, so this remains
vaporware until sometime tomorrow afternoon (CEST). Don't hold your
breath :)

Jesper



This archive was generated by hypermail 2b25 : Fri May 26 2000 - 18:45:12 CDT