But maybe time for some comments on the last of todays patches (the one I won't apply).
This is changing ParagraphList to a std::vector<Paragraph>. After playing around a bit I am convinced this is the way to go. First of all, there is really no performance problem withit whatsoever. E.g. splitting the first paragraph of the UserGuide.lyx leads to no recognizable delay although it moves all the contents of the document. You can check this yourself by changing the typedef and commenting out the 'splice' line in CutAndPaste.C which seemingly is the only time we use a std::list specific feature. Secondly, it gives us a trivial 'stable iterator' implementation. In fact, I even think we get drop the DocumentIterator::inset_ 'cache' as recreating this is O(nesting level) with the vector<> based par list, i.e. effectively O(1) on real world documents. You will notice, however, that after changing the typedef things go foobar for 'complex' operations. So we seem to rely on the fact that list iterators are 'semi-stable' (compared to vector iterators) under deletion/insertion. The easy way out is of course, to use offsets everywhere, and this is what patch 8 does. I am not done with it. Although most changes are purely mechanical, some are not. I also think this it is a good idea to let everybody getting used to the idea of a vector based paragraph list. Andre' PS: A rule of thumb I came up with during the 'playing around': O(n) is acceptable anywhere anytime as response to a user interaction. O(n^2) is not. With the vector based solution we never get worse then O(n), for list based this is tricky (if possible at all).
