Diff Preview Against Current File

[BrutalSimplicity]

Is it possible to show the diff against the current file rather than smaller diffs against the previous state?

If I'm looking back at a file that has many changes, I'd like to be able to see all of the changes between the previous state and the current state to better understand what I'd be undoing. I understand that might have greater costs to performance given a large undo history so maybe this could be a mapping to telescope that opens vimdiff against the changeset to preview all changes in full.

[debugloop]

I like the idea!

What telescope-undo does is basically calling undo on the real buffer and calculating a diff between each u call in between. When done, it restores to a given change ID that sits on top of the list, i.e. the current state. This means the performance will only be different by the additional diffs themselves.

However, each entry has the sequence number of the undo state attached, so calculating the "total diff" on-demand would be a single undo to that state (as <cr> does), calculate the diff, and switch the preview.

How would you envision the UX for that? The current "change diff" as a default, and a binding to switch the preview over to a "total diff"? I don't think it's possible to have two previews 😅 But I'm also not quite sold on this being a feature of the main telescope-undo telescope... maybe you're right and this should indeed be another telescope (offered by this plugin), but that would limit the ability to go back to the original view 🤔

What are your thoughts on this? I think a config switch for what to show ("change diff", "total diff", both??) is definitely doable, but I guess there's a way to integrate this nicely. I don't like that the "total diff mode" makes the yank addition/deletion completely useless 😅 Am I guessing correctly that your need for this is mostly for undoing changes, not yanking them out of a previous state?

[debugloop]

Oh, and the obligatory: If you're motivated to work on this I'm happy to help you out and answer any questions, but I'll get to doing it myself in time I assume 🦥

[debugloop]

I got around to implementing this, feel free to test it out and let me know your thoughts. It's available on branch feat/compare_to_current (here, comes with some docs in the README).

I played around with it for a bit and to be honest can't make much sense of it. Yanking is next to useless, and restoring states feels somehow not very intuitive... Not sure if the diff should be the other way around? Anyhow, let me know and test this, if you @BrutalSimplicity (or anyone, i.e. @ianwixon 👀) sees value in it I'll put it to main 👍🏻

Using require("telescope").extensions.undo.undo({compare_to_current=true}) to invoke for testing is the most convenient, probably ;)

[BrutalSimplicity]

Thanks for the work on this feature! But, I think you're right, it's a bit difficult to understand the diff being presented. It doesn't seem to be aggregating the changes from each undo point to reconstruct the old version of the file for comparison. It looks like it's showing the diff between each undo point against the current file, which gets pretty hard to decipher the further back in history I go.

I based this functionality from the timeline view used in VSCode. The way it seems to work is by saving the entire buffer after each change such that when you view the diff you're actually viewing the diff between the old and new version of the file, rather than a single change in history.

Since this plugin calculates diffs based on the undo history, this might be an out-of-scope feature. I would still find it very useful to have this type of view. Is it possible to reconstruct the previous version of a from the undo points that have come before it?

I think another approach would be to save your own versions of the file, but then it wouldn't really be leveraging the Undo History at that point.

I can annotate some screen captures to better explain if you think that might help.

[debugloop]

Well that's the weird part, it seems to work for the full diff for a test file, but the diff on a "real" history looks to weird to be the aggregation of it. If you can provide a small normal mode string (i.e. ifoo<esc>obar<esc>obaz<esc> works alright) which creates a bad diff you'd boost my efforts quite considerably, as I'm really unclear on what's happening...

Regarding undo states in vim, each state has a clear parent, and vim can restore to any state. I.e. you can use the the number from telescope-undo to run :undo 42 to restore the buffer to after that state (post diff). You'll also be able to go to the latest state this way.

The way I implemented this first version is grabbing the buffer on execute and substituting that for the "child".

[zippeurfou]

I use this to look at the difference between the unsaved buffer and the previous saved one.

local filetype = vim.api.nvim_buf_get_option(0, "filetype")
  vim.cmd("tab split | diffthis")
  vim.cmd("aboveleft vnew | r # | normal! 1Gdd")
  vim.cmd("diffthis")
  vim.cmd("setlocal bt=nofile bh=wipe nobl noswf ro ft=" .. filetype)
  vim.cmd("wincmd l")

Maybe it is about somehow comparing the different write event in the buffer that could help at a high level.

[debugloop]

This might have been looking so very weird because of #50. I'll look into it once I'm confident to put the fix for that onto main 👍🏻

[debugloop]

I've rebased the above mentioned branch with the proof of concept onto that recent fix, and now it looks like it's working 🎉 I'm still not sure whether it's very useful though, can you guys try it out and let me know whether that's what you'd expect?

[hvhaugwitz]

What is the state of this issue (and the feature branch)? Any chance this gets merged into main soon?

[debugloop]

I haven't heard back from anyone regarding whether it does what people expect. I take it you've tried it? Does it work for you?

Last I tried it, I found this way of presenting the diffs highly confusing. I think it's because I treat this plugin as a way to undo a couple of things or search and yank something I deleted. For moving between states I would always use git. I'm not opposed to merging at all, I just want to make sure that it does what the actual users think it should do (as I don't see myself using it 😁).

[hvhaugwitz]

@debugloop yes, I tested the branch and it does what I expect