jinfinote icon indicating copy to clipboard operation
jinfinote copied to clipboard

remote cursor position issue?

Open ghost opened this issue 14 years ago • 2 comments

I did some more testing on the remote delete position, but couldn't get rid of the problem. I cleaned up the editor code, and added some cleaner console output at http://94.23.105.24. It now looks like: DoRequest(6092, 754:7;1:1;2870:4;3482:112;4512:8;4706:4;4854:18;5336:90;5474:3;6092:23;7644:1, Delete(94, 1)) remote cursor @:94 translates to line:28 and offset:0

The problem occurs when having a text, then a bunch of \n\n\n\n\n\n\n\n\n\n and then some more text. Deleting one \n in the middle, will return a delete position thats at the end of the range of \n's, instead of on the removed \n itself. One thing i noticed was that the editor code-part that handles split operations doesnt get triggered. Maybe that's got something to do with it?

ghost avatar Mar 03 '11 11:03 ghost

As mentioned in the other issue, this is due to the way the diff-match-patch library detects changes in the text. Because it is unaware of the edit cursor, it can't tell which of the identical characters has been removed, so it chooses the last one. It hasn't been much of a problem until now because the end result, as far as the text content is concerned, is the same. I'm not sure right now how to easily fix this. The current cursor position after an edit needs to be taken into account for the diff somehow. Maybe by diffing the text before and after the cursor individually, but it's not trivial. Split operations can only occur when requests are transformed against each other, which does not happen if there are no concurrent edits, so this is not relevant to the issue.

sveith avatar Mar 03 '11 11:03 sveith

Sorry for double-posting. I should have followed that lead before. It's indeed the diff function causing the issue. I'll try to come up with a fix, and post it here. Thanks!

ghost avatar Mar 03 '11 11:03 ghost