-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Vim-like Persistent Undo #9154
base: master
Are you sure you want to change the base?
Vim-like Persistent Undo #9154
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
I am rethinking utilizing Thoughts on using blake3, reverting to sha1, or waiting on benchmarks and real-world testing? Edit: I found out about xxhash which seems to target this niche. xxhash-rust adds no further dependencies and its author is the same as Edit2: On second thought, I think it would be better to just not verify the undofile's integrity. The cost is not worth the rare case that it becomes subtly corrupted. I'll revert to sha1. |
6178527
to
e46d4e8
Compare
Regarding hashes and persistent undo: I agree that the undo file getting corrupted is unlikely, and probably not worth considering. However, as you've noted in the PR description, there is a high probability of the text file getting modified outside of Helix (checking out git branches, running auto formatters, making quick edits in other editors, etc.). So I think storing the hash for the text contents that the head of the undo file corresponds to does make sense, since time stamps can be fickle on some systems. And with that in mind, I think using a faster hash still makes sense, since you'll be hashing text file contents on load/save. IIRC blake3 is notably faster than any of the SHA hashes, even single-threaded. You might also consider tagging the hash value with what hash it is (Blake2, SHA1, whatever) so that it's easier to change it in the future if desired. |
Yeah it already was using a hash (sha1), but I've switched it to xxhash since it seems more geared towards this kind of thing (e.g. |
79476d1
to
6efad7b
Compare
I had a quick look at the code and can't find the config options, I assume I can turn this feature off? Also, I personally would like to see it off by default. |
Ah, I forgot to document it. It's |
can we proritize this ? a new version released . still no persistent undo |
I'm not currently working on major features for Helix for at least a few months. For the past few years, almost all my contributions have been to Helix, so right now I'm looking to focus on my own projects. This PR will be completed eventually, it'll just take longer. |
@kirawi want some help finishing this one up? |
I restarted work on this on a private branch already, and I'll try to get that over the finish line. If I'm not available for it, then I'll make that branch public and allow someone to adopt the PR. |
Just a minor status update: We'll be using an SQLite DB to host the persisted file histories instead of a bespoke file format. The underlying architecture will have to be significantly changed since revisions won't be serialized in the same way. Otherwise, I have addressed some bugs with the architecture that would undesirably overwrite valid undofiles or incorrectly merge to other clients. |
I'm fairly busy right now, so if anyone is interested and has the experience to tackle this, please message me on Matrix (I am djo_kirawi). Otherwise, I will continue to work on it as I am available. |
Resolves persistent undo as part of #401
Depends upon #9236
Differences from Vim's implementation
:history-reload
command that will merge the undofile's history to the instance's history. That way, it is possible for two separate clients to have worked on the same file and not totally erase the undofile. This command can be removed once it is implemented.Remaining Tasks
:w
to restore it).Notes
tenthash
could potentially be used in the future instead of blake3