Skip to content
This repository has been archived by the owner on Mar 3, 2023. It is now read-only.

Serialized markers are unserialized at the bottom of the buffer #1285

Closed
benogle opened this issue Dec 11, 2013 · 4 comments · Fixed by #1297
Closed

Serialized markers are unserialized at the bottom of the buffer #1285

benogle opened this issue Dec 11, 2013 · 4 comments · Fixed by #1297
Labels

Comments

@benogle
Copy link
Contributor

benogle commented Dec 11, 2013

You can see this in bookmarks:

  1. Make a bookmark.
  2. Reload the editor
  3. See bookmark at the bottom of the buffer. Why?

My assumption is that the buffer is reloaded / set again after the markers are deserialized. If anyone has any insight into this, lemmie know. I'm going to dig in a bit.

atom/bookmarks#3

@nathansobo
Copy link
Contributor

Curious what you're seeing. My first suspicion would be that we're overwriting the text of the buffer, but cursors remain stationary on reload so that seems to rule that out.

@benogle
Copy link
Contributor Author

benogle commented Dec 11, 2013

This is because we call TextBuffer::load() after creation which loads the buffer from disk, runs a TextBuffer::setText(), and displaces all the markers. A quick fix would be to not reload unless the disk buffer is different from the current state of the editor.

I'm going to take a stab at making TextBuffer::setText() to do a line-wise diff application tomorrow. (using https://github.com/kpdecker/jsdiff; also take a look at https://github.com/cemerick/jsdifflib)

benogle added a commit that referenced this issue Dec 12, 2013
Previously, it would blindly read from disk on reload, and set the text 
into the editor. This was problematic as it would mess with markers and 
folds. No longer. 

Fixes #1285 and fixes atom/bookmarks#3
@nathansobo
Copy link
Contributor

@lock
Copy link

lock bot commented Jan 27, 2019

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

@lock lock bot locked as resolved and limited conversation to collaborators Jan 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants