Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle markers properly #22

Open
jackkamm opened this issue Sep 6, 2019 · 3 comments
Open

Handle markers properly #22

jackkamm opened this issue Sep 6, 2019 · 3 comments

Comments

@jackkamm
Copy link
Owner

jackkamm commented Sep 6, 2019

PR #21 by @takaxp fixes a problem with org-clock-marker, but this problem is a symptom of a deeper problem, that we don't currently handle markers in the undo-propose buffers.

References

Additional Notes

There are entries in the undo-list which adjust marker positions. When in the undo-propose buffer, (eq (marker-buffer m) (current-buffer)) is false so these entries are skipped.

One possible way to handle markers would be to copy the markers over to the undo-propose buffer, and edit entries in the undo-list to use the new markers.

@jackkamm
Copy link
Owner Author

@jackkamm
Copy link
Owner Author

As a workaround until we've found a permanent solution, we could create a list undo-propose--markers-to-check that we could add markers to (e.g. org-clock-marker from #21), and undo-propose will check for those markers and make copies to keep track of & update them.

@takaxp
Copy link
Contributor

takaxp commented Sep 13, 2019

Yes. The important thing is that we actually don't need to handle all markers in a buffer. It is also hard to identify which markers should be checked by us for all existing packages. I think it is a good choice that only registered markers will be handled properly.

In the case of org-clock-marker, we don't need to always copy the marker and also the original maker in the original buffer shouldn't be touched in the case of calling undo-propose-cancel.

In my understanding, the markers will not be actually copied but forked from the original marker for editing works in undo-propose buffer. If we commit the buffer with some undos, then the original marker shall be updated (normally updating the position). If we don't commit, then forked marker will be just trashed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants