On Thu, Mar 15, 2007 at 06:36:15PM +0100, Abdelrazak Younes wrote: > My point is that is not equivalent. A tree-like approach will inevitably > lead to cleaner and shorter code, I am 100% sure of that. Besides, I > still have difficulty to grasp the cursor slice concept. Make a poll in > the list and you will realise that close to nobody really understand the > cursor and cursor slice related code. For example I still don't know > how to select a text between two Cursors...
Asking might help. Create a new cursor (or reuse one of the two you got) with the DocIterator part being the DocIterator part of the first cursor and the anchor_ part being the DocIterator part of the second. Of course there are restrictions. The DocIterator part may not be nested further than the anchor_ part. > The reason is obvious: the Cursor approach hides the internal memory > structure. It is complicated because it does not have a simple mental model. It surely has. In the main inset go down to cell slice[0].cell, walk down to paragraph slice[0].pit, go to pos slice[0].pos, Take the inset there. Go to its cell slice[1].cell, paragraph slice[1].pit, position slice[1].pos. And so on. Ordinary text insets have a single cell only, tables and a lot of math insets may have more than one. > IMO, the Cursor (the DocIterator really) should only be used to move > the cursor logically within the document and nothing else. The dociterator is a pretty stable method to access a position in a document independent of the actual memory layout. It can, e.g., be readily dumped into a .lyx file. This is not immediately possible with the pointer approach. > And I reckon that the code in DocIterator.C will be dramatically > simplified if we had access to the parent (because there is only one) > and children in an easy way. Not really. We had the parent way for about ten years, yet no way to iterate over the document. So implementing it was obviously not trivial as having no way to iterate over a document hurt a lot... > >The only difference is that the recursive parent code is not > >implemented, but the code to scan a cursor is already here. > > Sure, three lines of code is really difficult to implement ;-) There are more implications. You need to fix up stuff when copying things as you lose value semantics. I am not saying the parent approach is wrong. However, it has a lot of implications. A whole lot. Andre'
