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

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

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

jdtsmith
Copy link
Contributor

@jdtsmith jdtsmith commented Jul 3, 2024

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
Copy link

fapdash commented Jul 3, 2024

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

@ideasman42
Copy link
Contributor

ideasman42 commented Jul 4, 2024

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
Copy link
Contributor Author

jdtsmith commented Jul 4, 2024

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
Copy link

fapdash commented Jul 4, 2024

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?
2024-07-04_20-22

Relative timestamp could show days for more than 24h:

2024-07-04_20-02

@jdtsmith
Copy link
Contributor Author

jdtsmith commented Jul 4, 2024

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

@fapdash
Copy link

fapdash commented Jul 4, 2024

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
Copy link
Contributor Author

jdtsmith commented Jul 4, 2024

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.

Use a simple ISO-formatted timestamp as key, and an annotation
function for additional information (records, percentage).
@jdtsmith
Copy link
Contributor Author

jdtsmith commented Jul 6, 2024

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:
image

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

Successfully merging this pull request may close these issues.

3 participants