> >> It's pseudo-rubbish in that the lyx data structure is a tree > >> in-concept only. It's actually a std::list<Paragraph> where each > >> Paragraph contains a std::vector<char> and an InsetList. Insets are > >> identified in the std::vector<char> by chars with value > >> 'META_INSET' and a Buffer::inset_iterator class enables one to go > >> from a (ParagraphList::iterator, lyx::pos_type) pair to the inset > >> of interest. > > > > The inset lists are actually located in each paragraph (not that it > > matters, but...). > > I know. I even described it as such ;-) > > >> At least that is my understanding of things. > >> > >> Nonetheless, your basic idea is a good one. > > > > But some insets recursively contain a std::list<Paragraph> etc. So > > it *is* a tree. > > Doh! I'll get back under my stone.
Given all that, wouldn't be using explicit tree structures the simplest thing in order to clean the core up some? I mean, if we operate on a tree, why not have the proper tree base classes made, and have a basic cursor with virtual methods which by default only knows how to go around those tree elements (takes care of say removing a paragraph automatically). Now, for each type of node and leaf (i.e. each inset type), there would be a specialized cursor subclass that implement methods to navigate that inset. I know there was some discussion about many-insets-in-a-single-inset vs. single-inset-in-a-list-of-many and it was quite heated. But if all we need are some real down-to-earth tree structures, why not just use them explicitly? I guess the code would be way clearer that way. Anyway, knowing how things are these days, I presume it's not something that will happen for 1.4 :) And now you'd see me exercising my (unexistent) sprinting skills :) Cheers, Kuba Ober
