[WebODF] Adding spec property "setOwnCursor" for Insert/Remove/Split ops

[Friedrich W. H. Kossebau]

Am Montag, 24. Juni 2013, 12:27:46 schrieb Jos van den Oever:
> On 06/24/13 12:19, Friedrich W. H. Kossebau wrote:
> > Am Samstag, 22. Juni 2013, 00:10:40 schrieb Jos van den Oever:
> >> On 06/17/13 12:39, Friedrich W. H. Kossebau wrote:
> >>> Hi WebODFler,
> >>> 
> >>> I would like to add a new property to the specs of all
> >>> insert/remove/split
> >>> ops: setOwnCursor (or some better name). This property will tell if the
> >>> cursor of the member which sends the operation should be put after the
> >>> place/result of the op.
> >>> Currently this is only done iff the cursor is at the position of the op.
> >>> But with real OT, where local operations are instantly applied and only
> >>> then sent to other clients who might have to transform them on
> >>> conflicts,
> >>> the transformed operations and positions of cursors can be out-of-sync,
> >>> breaking the current assumption with UI editing that cursors will always
> >>> automatically placed behind the places of modification.
> >> 
> >> Ok, I wrote a long email with different scenarios and orders of
> >> operations. I have discarded this mail because I came to the conclusion
> >> that the problem is not with the occurrence of an out-of-sync with an
> >> assumption of how cursors should move upon inserting or deleting text.
> >> 
> >> Here is the original example. I have added a | to show the insertion
> >> point.
> >> 
> >>     <text:p>|<cursor memberid="A"/><cursor memberid="B"/></text:p>
> > 
> > Why do you put the insertion point before the cursors? How would you
> > argument for this ordering? Why this way do you bound the cursors more to
> > the following and less to the preceding content?
> 
> A quick reply to only one question. I did read the rest of the mail.
> (I"m on holiday the whole week and shoudnt even be reading my mail.)

Thanks for the quick reply. Though it was not my intention to pull you out of 
vacation now, was expecting your reply next week. Was rather hoping for 
comments from the rest here for now :)
And this reply again is only expecting a reply from Jos next week, so resist 
to read now, Jos (please don't make me feel to spoil your free time) :) 
Everyone else, please do. The reading.

> The reason I put the insertion point where I put it, is that that is
> where README_cursorpositions.txt tells me to put it. That document
> describes cursor positions. Now, <cursor/> is ignored in that reasoning
> normally, but if it werent, youd get
> 1) <text:p>|<cursor memberid="A"/><cursor memberid="B"/></text:p>
> and
> 2) <text:p>a|<cursor memberid="A"/><cursor memberid="B"/></text:p>
> Why? because README_cursorpositions.txt says:
>   1) put | at start of empty paragraph, so before cursor
>   2) put | directly to right of a character

Hm, that seems cyclic reasoning in my after-lunch brain-state: "if it werent 
[ignored]" it would be|<cursor memberid="A"/>, because "1)  put | at start of 
empty paragraph, so before cursor."

But isn't | exactly the place where all the cursors hang around? Like 
README_cursorpositions.txt says:
	"The possible cursor positions are indicated with |".
And while we surely all imply that cursor position is also the insert 
position, it does not say something about the inner order at that position. 
Nor is the order given of all the cursors at that position, neither is it said 
that inside that position there is a sub-position for inserting, right before 
the sub-positions of the cursors.
So if that was to be supposed to be expressed in the docs, it needs to be done 
more explicitely, at least I could not read this there. And still would argue 
against it.

"because it's like that in the spec" does not (yet) hold for me. Worse, for my 
POV I would rather point out to "it's like that in the code" where only the 
editing cursor is moved behind the inserted object on paragraph split or text 
insertion.

> Please consider the solution I wrote initially. It is simple and
> consistent with our cursor position documentation.

I am considering it. But as result also questioning :) While it may be simple 
(but cannot see the consistence with the docs), there are the reasons for 
another solution, like given in the other email :/
Will see to find enough stuff else to work on this week so I can postpone any 
big work on this until you, Jos, are back with full concentration so we can 
sort out the differences we have here and find common ground.

Cheers
Friedrich
-- 
Friedrich W. H. Kossebau // KO GmbH
http://kogmbh.com/legal/