You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Litewrite will jump to a different document after launch/initial sync (I guess in case another one was active on a different device). This is especially bad when on a slow/mobile connection, but also on desktops when e.g. on a train for example. Worse, when you start writing a new note before sync has finished, you can lose those changes after sync I believe.
I haven't looked into it, but I would assume the cursor position is stored in the remote storage instead of locally. If that's correct, I think the best solution would be to store that bit of information in local storage instead.
The text was updated successfully, but these errors were encountered:
raucao
changed the title
Don't jump to different document after initial sync
Prevent jumping to different document after initial sync
Dec 27, 2017
I have seen that issue too. It's definitely annoying.
You guessed right regarding the cursor position. But I don't see how cursor position is related to which document is open?
Not sure how to best solve this though. The currently open document is loaded from the URL or whatever document is at the top of the list. I tried changing something. You can give that version a try on http://litewrite.github.io/litewrite, let me know if it works.
Do you have any way to properly reproduce it? Then I could also test it locally.
Currently Litewrite will jump to a different document after launch/initial sync (I guess in case another one was active on a different device). This is especially bad when on a slow/mobile connection, but also on desktops when e.g. on a train for example. Worse, when you start writing a new note before sync has finished, you can lose those changes after sync I believe.
I haven't looked into it, but I would assume the cursor position is stored in the remote storage instead of locally. If that's correct, I think the best solution would be to store that bit of information in local storage instead.
The text was updated successfully, but these errors were encountered: