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

Diff Preview Against Current File #40

Open
BrutalSimplicity opened this issue Oct 17, 2023 · 8 comments
Open

Diff Preview Against Current File #40

BrutalSimplicity opened this issue Oct 17, 2023 · 8 comments
Assignees
Labels
enhancement New feature or request

Comments

@BrutalSimplicity
Copy link

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

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 debugloop added the enhancement New feature or request label Oct 28, 2023
@debugloop
Copy link
Owner

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

debugloop commented Nov 12, 2023

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 ;)

@debugloop debugloop self-assigned this Nov 12, 2023
@BrutalSimplicity
Copy link
Author

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

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

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

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

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants