75522Re: [patch] :undorecover command
- Mar 7 11:45 AMChristian Brabandt wrote:
> here is a patch, containing an :undorecover command that has beenThanks. Setting that 'undosavebuf' sounds a bit dangerous...
> requested before. If you apply this patch and use :undorecover on
> existing undofiles, it will simply read in the undo structure.
> But by itself this isn't really useful, as one probably ends up with
> only many small pieces of the original file and most probably not the
> complete file contents. But at least one can traverse the undo structure
> and see if one can at least recover parts of the file.
> Newly written undofiles will therefore at least contain one complete
> buffer content at the time the undofile is written and no complete
> buffer content has been recorded yet. When using those undofiles
> together with :undorecover one will jump to that state in the undo tree
> and from there one can try to recover parts of the file.
> But even then, if one has many undo branches, there will be most likely
> branches, that are not recoverable, because the undo information does
> not contains information to recover from that initial state.
> Therefore, this patch also adds an 'undosavebuf' option (off by default)
> which when on, will always save the complete buffer in the undo tree
> whenever the undofile is written. This possibly makes the undo tree (and
> undofile) a lot larger, but the user should be able to recover different
> states pretty easily.
If I understand it correctly, the user will have to go forward and
backward in the undo tree to find useful text. And there will be many
versions of the same line. Perhaps it's possible to be more clever and
just start with buffer with empty lines, and go through history in a way
one ends up with the last known state of each line? I know this isn't
easy, but it should be possible.
Also, this is difficult to test with something under src/testdir. It's
probably more suited for a unittest like memfile_test.c does.
"When I die, I want a tombstone that says "GAME OVER" - Ton Richters
/// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
For more options, visit https://groups.google.com/d/optout.
- << Previous post in topic Next post in topic >>