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

feat(commands): better handling of buffer-close #1397

Merged
merged 4 commits into from
Apr 27, 2022
Merged

feat(commands): better handling of buffer-close #1397

merged 4 commits into from
Apr 27, 2022

Conversation

matoous
Copy link
Contributor

@matoous matoous commented Dec 29, 2021

Previously, when closing buffer, you would loose cursor position in other docs. Also, all splits where the buffer was open would be closed.

This PR changes the behavior, if the view has also other buffer previously viewed it switches back to the last one instead of the view being closed. As a side effect, since the views are persisted, the cursor history is persisted as well.

Fixes: #1186

@matoous matoous marked this pull request as ready for review December 29, 2021 10:37
@matoous
Copy link
Contributor Author

matoous commented Dec 29, 2021

(fixed some typos in the commit message by amending)

@archseer
Copy link
Member

\cc @cole-h

Copy link
Contributor

@cole-h cole-h left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like it may make sense to turn the last_accessed_doc into a tree of last accessed documents. That might help avoid the issue of switching to the last accessed document but not updating that field (so it's pointing to the same document we just switched to). Then, just remove the document from the tree and let it rebalance itself to have a new "last accessed document". Thoughts? (This probably isn't appropriate for this PR, however, but would make this buffer close stuff more robust.)

helix-view/src/editor.rs Outdated Show resolved Hide resolved
helix-view/src/editor.rs Show resolved Hide resolved
@matoous
Copy link
Contributor Author

matoous commented Dec 29, 2021

@cole-h I might be missing something very elemental here, but why is tree needed and not vector for the last accessed docs?

@cole-h
Copy link
Contributor

cole-h commented Dec 29, 2021

Ordering is something I had in mind. It would be nice to be able to move forward and backward in the "history" of recent docs, but maybe that's complicating things too much. A Vec may very well be more useful / desired / simple: just push the last doc to it when switching away, and then pop from that list when wanting to access that doc.

@matoous
Copy link
Contributor Author

matoous commented Jan 4, 2022

@cole-h thanks for suggestions. I refactored the PR. I am still hesitant if this is the correct approach. I was toying around with the result and encountered a few issues (that I tried to fix) with for example document in the history being closed. I am not sure what the right approach here would be. Ideally we might also store the document path in the history and if view tries to access closed document we re-open it?

@matoous
Copy link
Contributor Author

matoous commented Feb 11, 2022

@archseer when you have some time left, would you please take a look at this PR? 🙏 most importantly the above comment

@archseer
Copy link
Member

example document in the history being closed

That's a bug, such documents need to be removed here:

pub fn remove(&mut self, doc_id: &DocumentId) {
self.jumps.retain(|(other_id, _)| other_id != doc_id);
}

This is how we clean up the jumplist when a document is closed.

Comment on lines +98 to +125
pub fn add_to_history(&mut self, id: DocumentId) {
if let Some(pos) = self.docs_access_history.iter().position(|&doc| doc == id) {
self.docs_access_history.remove(pos);
}
self.docs_access_history.push(id);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like it could continually grow and leak memory. It would be good to truncate to a certain max length.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The if above prevents a single document from being multiple times in history, thus the size should always be <= number of documents and those are un-capped too as far as I am aware, I don't think the limit is strictly necessary here, but I can add it for sure.

helix-view/src/editor.rs Outdated Show resolved Hide resolved
matoous added 4 commits April 21, 2022 14:16
Previously, when closing buffer, you would loose cursor position in other docs.
Also, all splits where the buffer was open would be closed.

This PR changes the behavior, if the view has also other buffer
previously viewed it switches back to the last one instead of the view
being closed. As a side effect, since the views are persisted,
 the cursor history is persisted as well.

Fixes: #1186
@matoous
Copy link
Contributor Author

matoous commented Apr 21, 2022

@archseer sorry for long period of nothing, I had a lot of work recently. I got back to this PR and tried to fix it based on suggestions. Would you please take a look one more time?

@CptPotato
Copy link
Contributor

I think this also closes #2034

@the-mikedavis
Copy link
Member

This may close #2107 as well

@archseer archseer linked an issue Apr 22, 2022 that may be closed by this pull request
@the-mikedavis
Copy link
Member

Just gave this a try and I can't reproduce the jump-backwards panic (#2107) with it 🎉

@archseer
Copy link
Member

@matoous No problem, welcome back! 🎉

@archseer archseer merged commit 52f5a42 into helix-editor:master Apr 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants