On Tue, Jan 20, 2004 at 01:43:39PM +0000, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> >
> > This reduces the mathcursor class to a namespace and moves some
> > stuff to LCursor and InsetBase.
> >
> > There are still 2500 lines to move (1400 from amthcursor and 900
> > from formulabase) and it is still full of 'off-by-one' crashes but
> > things are snapping into place.
> >
> > Andre'
>
> I lik ethe changes to BufferView.[Ch]. Those to BufferviewPimpl.C are
> pleasing to the eye too even if I don't know the nitty gritty.
>
> This looks suspicious:
>
> Index: bufferview_funcs.C
> string const currentState(BufferView * bv)
> {
> + if (inMathed()) {
> + bv->cursor().info(state);
> + return state.str();
> + }
>
> why is inMathed() a global function, independent of 'bv'?
It's a hack. Formerly just a test of an existing math cursor. This is
going the same way as the mathcursor itself.
Well, it's hard to do everything at a time in a 'reasonably sized'
patch.
> LCursor class has suddenly got a lot more complicated. Witness the 5
> extra veariables initialised in the c-tor.
It just the selection flags from bufferview and the 'autocorrect_' and
'macromode_' flags inherited from the math cursor. And 'current_'...
> What's the current_ slice? I thought that the cursor (blinking thing)
> was always the top-most slice.
We are dispatching to the innermost inset willing to handle an LFUN.
This means going down the slice stack. Of course we can't just pop
slices while _trying_ to dispatch as the handling inset might just want
to pop up a dialog but not move the cursor tip at all. 'current_' is
the 'interesting' slice in then stack. Therefore, an inset's dispatch
just needs to access 'cur.pos()' to get the cursor position in the slice
it is supposed to look at (which is not necessarily the cursor tip)
> Do you have any plans to address the nastiness in LCursor::getPos?
Well, I don't intend to enter all math at position (100,100), so this
should be obvious.
> Why does LCursor::innerInsetTabular() exist? Shouldn't this be a
> wrapper function in an anonymous namespace in insettabular.C?
Possibly, yes.
> Will the LCursor member functions returning MathArray et al. survive
> IU or will they eventually dissappear?
Not sure. I guess they'll survive. The texted analogon is 'Paragraph'
and MathArray and Paragraph are (a) the basic storage containers for
mathed and texted, respectively, and (b) (currently) too different to be
put into a single class.
Note that I aim at giving them some 'uniform access' from the POV of the
LCursor user. 'lastpos()' e.g. returns paragraph().size() for texted and
cell().size() for mathed, so in the best possible scenario we'll keep
the difference hidden as an implementation detail in the cursor.
> I see you've move stuff out of cursor_slice and into cursor. cursor
> becomes an STL-like container, it would appear.
Not really. It'll be a blend of the selection part of the bufferview and
the math cursor. I'll do whatever is necessary to
> Why are these now public? Surely you've added all sorts of accessors?
> Note that 'wee' should be 'we'.
> cursor.h
> public:
> +//private:
> /// mainly used as stack, but wee need random access
> std::vector<CursorSlice> cursor_;
> - /// The
> + /// the anchor position
> std::vector<CursorSlice> anchor_;
> - ///
> - BufferView * bv_;
> +
>
> what happened to fullCursor? It appears to have died.
Renamed to 'cursor()', old 'cursor()' renamed to 'current()' and using
'current_' instead of 'back()'
> Woooooooooooooooooooooooo! InsetOld::Code has gone!!!!
No. Shifted to InsetBase.
I am not happy about it. I'd pretty much prefer the 'asFooInset'
solution (which works for inheritance, too), but not as extensive
as it is currently used by mathed. I.e. I'd accept maybe six special
cases, but not 30...
> Oh. Only as far as UpdatableInset. I see it has actually gained a
> couple of mathed values.
>
> Actually, I really like what you're doing here. Even someone as
> ignorant as me can see taht this is turning out much, much cleaner.
The current patch contains a few nasty crashes. Nothing conceptionally
serious, but crashes nevertheless.
So you basically have a choice of a 270k buggy patch applied and waiting
for an even larger one.
> Keep going, papa!
I've two more nights of
Andre'
