Subject: Re: Summary (was Re: asserts and pagebreaks)
From: Mike Nordell (tamlin@algonet.se)
Date: Mon May 22 2000 - 18:46:41 CDT
Jesper Skov wrote:
> Mike> Please, share your insight on why is it needed. With my
> Mike> ignorance I still think a method "isInside()" should be wnought,
> Mike> so I'd really like to know _why_ this is needed.
>
> isInside may do the trick, I don't know. Haven't looked at that yet.
>
> [This is why I think it's necessary. May be wrong..]
>
> But the JUSTAFTER is necessary (in the current implementation) to
> catch the case (or cases like it):
>
> page0:
> ..., Run n-2 (text), Run n-1 (text), Run n (pageBreak),
> page1:
> Run 0 (text)
>
>
> When scanning along the list, the function needs to return the coords
> for Run n-1 in the above. That's now done by having a Run guess at if
> the following Run is the last on the line/page - in which case we
> terminate the search.
That's IMCO (In My Current Opinion - new acronym?) bad. A run should only
know about itself and the stuff I mention below.
> You suggested having a Run return either "inside" or "outside". That's
> not quite enough, I think - and probably the reason for the current
> implementation.
I don't know that I suggested it, but I did mention it. If everything
regarding "before" or "after" was handled (as it probably should be) by
the owner class (fl_BlockLayout) it wouldn't be a problem I think. Maybe
fl_BlockLayout should get additional responsibilities, like being able to
give you the next run?
> I've been pondering a rewrite where the Runs return "inside" or
> "I'm-past-the-point-you-are-looking-for". In the latter case, return
> the previous (text) Run coords.
Please don't, I'd rather see that its owner handles this. A run should
IMO *only* know about itself, its position on the fp_Line, its DocPos wrt
the block and a few other things. It should know nothing about other runs
(in a perfect world).
> Now, it's basically the same semantics, but I like that approach
> better because the loop can keep a variable with the last
> known-to-be-valid-for-IP Run and return it if getting past the
> position that is searched for.
Now we're getting down to business: semanics. I've always wondered why
runs are chained in a d/l list and *also* participate in a fp_Line
collection. With my limited experience with these collections I'd like to
say: drop the d/l run-list for a collection in fl_BlockLayout.
With the current semantics I've numerous of times been led to believe
that runs participated in their d/l list within an fp_Line. Needless to
say I was wrong. I think that displays that the sematics are wrong: If a
(possibly quite experienced) developer thinks one thing, and it shows to
be quite another way, it might be an indication that the collection is
wrong.
> Also, I changed the code to print out exit point of the
> function. Majority of calls return at 'return p' and 'if lv' in the
> above. Probably obvious, but in the current implementation it means
> that the block's list of Runs is iterated over in its entire length
> twice at each call while you are typing (i.e., cursor at the end of a
> line).
>
> Probably doesn't amount to much performance wise,
Try (with a debug-compiled version) to type "blah blah" or whatever until
you reach 5-10 lines (depending on how insanely fast your machine is),
you should mention some delay. If not visible, try (if your OS allows it)
an audiable hint (like the one in my cursor patch), I noticed a great
performance hit there. Maybe, just maybe, that delay could be attributed
to that behaviour? I haven't run AbiWord through a profiler yet since
there's still bugs and basic functionality missing.
> I'm pretty naggered and haven't actually looked at the code since
> yesterday, so I may have missed something obvious.
Now this is dedication: "since yesterday". Keep it up Jesper!
/Mike - please don't cc.
This archive was generated by hypermail 2b25 : Mon May 22 2000 - 17:44:24 CDT