Add truncate-at-node for timestamp-based undo-list truncation

[jdtsmith]

Includes new key binding K to select a (saved) node by date, and truncate the undo-list prior to that node. Works well in limited testing. We could also add a "truncate to this node" binding if we wanted, which would work in all buffers.

After refreshing, this also resets vundo--roll-back-to-this, which I might argue should be performed in vundo--refresh-buffer (since the nodes will have changed from entry). What do you think @casouri?

[fapdash]

@jdtsmith Thank you, will test this tomorrow. :)

[ideasman42]

Note that I like the fact Vundo is currently read-only (you generally can't accidentally delete undo history), if this changes I think it'd be good to have an option to prevent any destructive operations. I never want Vundo to perform destructive operations, just navigate the undo history and apply or quit.

If this moves in the direction of manipulating undo history, it could even be a separate package, functionality could include:

• Delete all future steps (redo information).
• Delete branches (make history linear).
• Keep N-steps.

[jdtsmith]

This would never be automatic, and you don't need to invoke the command of course. Interactively it prompts you both to select the date prior to which to truncate history, and a confirming Permanently remove all undo information prior to XXX? to which you have to respond "yes". So it's decidedly "opt-in".

Note that vundo does alter history as part of its normal operation, trimming "unnecessary tails" of the list, which accumulate rapidly due to the way it navigates history. This is mostly but not entirely lossless; see #66.

One issue driving this is for users of undo-fu-session or similar, the undo list can grow quite large relatively quickly, and vundo doesn't handle that well (mostly just from emacs' long-lines issues; see #106).

[fapdash]

Mhh, don't really know how I managed but sometimes I get timestamp options that don't result in any change when I reset to them:

Peek.2024-07-04.20-18.mp4

Peek.2024-07-04.20-21.mp4

Would it make more sense to show the absolute timestamp in the confirmation?

Relative timestamp could show days for more than 24h:

[jdtsmith]

If the base of the list has a timestamp, truncating there will not remove anything. Is that what you are seeing?

[fapdash]

In the first video I choose the option with the earlier timestamp and nothing happens, I choose a more recent timestamp it it truncates. Is this a possible scenario?

[jdtsmith]

Yep that's what I meant. I pushed a small change to filter out nodes the truncation to which won't actually remove anything. See if that fixes it for you. I also provide a message indicating how many records were removed. And I changed the time format mentioned in the yes/no prompt. Update: I also added some record statistics to the completing-read prompt so you can see how much you will be removing.

[jdtsmith]

Updated to use an annotation function for the "extra" information. Normal completion now just selects on a timestamp, like 2024-07-04T15:54:40-0400. Let me know how it's working.

Looks like: