Andre Poenitz wrote:
> > longer a concern and you can use a clearer implementation. Coming to
> > think of it, you can completely do away with the integer 'floor' by
> > moving some of the logic into the virtual methods -- something like the
> > following (please excluse fictive class names):
> > virtual array<MathInset> getSubinsetsBelow(MathInset* subinset);
> > or possibly even:
> > virtual MathInset* getSubinsetBelow(MathInset* subinset,
> > CursorPosition pos);
>
> Now it looks pretty similar to
>
> bool MathInset::idxDown(int & idx, int & pos)
>
> which tries to move the cursor cell idx "down" (and adjust the position
> "pos" in that cell), and returns success or failure...
>
> So, indeed, we are not too far away from each other now.
Yup, it's better without the C-think of my original proposal. :-)
But we still want to traverse the tree (to recall: upon <down> we move
up the tree until we reach a node that has a lower subinset, switch to
that subinset, then go down always picking the highest descendant; in
the process, whenever there are several choices with the same vertical
positioning, choose visually according to horizontal cursor location).
So we have three sets of queries (each consisting of an up+down couple):
1. "Where to go upon <down> keypress?" == idxDown()
2. "Here's a subinset of yours. What is the highest subinset
that's below it?"
3. "Here's a subinset of yours. What is the highest subinset
that's below it and can be entered from outside?"
The up-traversal uses Type 2 queries and the down-traversal uses Type 3
queries. They differ since you want to enter some insets in Type 2 but
not in Type 3 (anything except script insets in this category?), but
they're often identical so it's reasonable to implement them using the
same function with a bool parameter.
It's not *that* far from the 50 LOC goal, I think.
Eran
