Andre Poenitz wrote:
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.
I've done that, many times may I add. Even Michael has asked many times
and I believe he managed to find the solution by himself at the end
(which I don't remember).
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.
I've tried that. Problem is I didn't manage to make it work for any kind
of selection. If you could write for me a method that will save the
current selection state so that it can be restored afterwards it would
help me a lot for some experiment I've done related to scrolling.
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.
Am I the only one who think this is not simple?
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.
I agree. And as I say the dociterator is very nice for this use-case.
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...
Come on, look at DocIterator::forwardPos() and backwardPos(), I am
pretty sure this could be simplified by having access to the tree
information.
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.
As I said, I am not advocating a complete switch to the parent approach.
Anyway, as Georg said, we have other matters at hand right now.
Abdel.
