On 29/04/13 23:32, Nico Williams wrote:
>> However, when considering that other users might be editing stuff
>> above/before our
>> cursor position, then it means this way of referencing positions within the
>> text
>> should be changed/reworked to a pointer-based one.
>
> But what alternative addressing schemes could there be?
well, when I wrote pointer, I actually meant C/C++ pointer :-). It's fixed,
it doesn't change, it simply refs the paragraph, regardless of what other
paragraphs precede it, or whether it is moved around (ParagraphList is a
list, isn't it ?)
Now, the problem comes when deleting a paragraph: we need to check that no
other cursors are on it, otherwise either forbid the operation or move the
other cursors at the end of the removed part.
Further issue is characters, as there's no list of characters in LyX, AFAICR,
but it's a contiguous array. So, for chars there seems to be no other way
than keeping a pos index..., or reworking that as a CharacterList.{h,cpp},
which I'm quite sure somebody wouldn't like.
Given also issues raised in that a newcomer should not be messing around the
core of LyX and refactor the cursor, because of the risk of entering a
stability nightmare, it may be valuable to consider to keep the cursor as
it is, and instead add the necessary logic to modify affected cursors of
other concurrent editors consistently with the action.
For example:
-) when inserting a new character (LFUN_SELF_INSERT):
for each cursor in same par in positions beyond this, do a pos++
-) when inserting a new par (on Enter):
for each cursor in later pars, do a pit++
-) others for cut'n'paste, etc...
-) I know, cases will grow fast...
> I'm thinking
> of a hash-based scheme, something like {{hash of paragraph contents},
> offset into paragraph.
while extremely git-ish :-), it would have the problem of identical paragraphs
that are very possible in documents (e.g., right after a copy'n'paste).
T.
