Suggestion: Add option to view backups as diffs

[unphased]

I really like the ability to use keyboard shortcuts to quickly flip through the history. This is really great.

Thanks for responding to my post on the userecho!

I also like the other plugin's functionality which can display changes as diffs. This is good because there is automatic color highlighting. Would you be interested in adding this? Have an option which once enabled, rather than displaying the currently viewing backup, display the diff between the working copy (most recent) and the currently viewing backup. Once that works it could also be extended to allow displaying the incremental diff (between the one being viewed and the one after it), rather than the global diff.

I'm loving this plugin though. I think I will use both! not efficient use of disk space though :D

[joelpt]

I'll definitely implement a diff feature sometime soon. I'm undecided exactly how it should work.

One option is to have a "Show Diff" hotkey/command that opens a new buffer with the colorized diff in it. Another is per your suggestion, showing the diff in the current buffer. I tend towards the former approach because I often will browse a step or two back in the history and then save that version of the buffer, to quickly rollback some changes I'd made. I could certainly make an option that controls whether the diff goes into the current or a new buffer, though.

What I'd really like to do is implement side-by-side visual compare directly in ST2 in the style of Beyond Compare -- as in these screenshots:
http://i.imgur.com/8m7Yj.png
http://i.imgur.com/3JxOM.png

ST2 has code-folding in place so the "collapsed sections" approach that you see in these screenshots should be possible with that. And maintaining the proper scroll position between the two views shouldn't be too hard. I have also seen examples of plugins putting custom icons in the view gutter, though I'm not sure if it is possible to wire up custom on-click handling for those. That would be ideal though, to let the user easily transfer a line or section from one pane to the other.

The part I am really not sure about is how feasible it is to do colorization of the text denoting differences. I suspect it is possible though.

That being said, doing a true side-by-side comparison will be quite an effort, probably considerably more work than the automatic-backups plugin itself took. So I will likely just implement a simple diff view/buffer as you described first; the Local History plugin by another author has implemented this so it should not be much more than a copy-paste-tweak job to get it working.

Regarding disk space, Issue #1 on this tracker is for adding backups pruning functionality. That will probably be implemented about the same time I get around to the diff function. Personally I really like having a comprehensive history of my files "to the beginning of time", but you're right, the disk space issue may be a problem for some.

[unphased]

I believe (i'm not sure) the way you have the functionality implemented currently in this plugin is that once the user starts browsing backups, the current buffer of the file is not saved, and the buffer itself is modified by filling in the contents of the backups (as you scan through them).

This works pretty well! But opening the backup view inside of a new transient view will allow us to not destroy current work progress on the file. On the other plugin (local-history: https://github.com/vishr/local-history ) commit c1ce9289 has a pretty good incremental diff transient view functionality. I've been playing with a fork from there, attempting to hook up a keyboard command to it, but haven't gotten very far yet.

A proper side by side visual compare would be awesome but I'm not sure just how limiting the ST2 API is going to be. Colorizing is a must and without the central curved "which goes where" view (like this http://aoeu.se/so/diff-viewer-api.png ) it can't compete with other diff utilities.

The key to enhancing ST2 with history/backup functionality is primarily speed. We flip through versions of save history with a keypress right in the editor, and that kicks ass. For heavy duty diffing functionality my opinion is that unless the author decides to spend some time to make a proper diff UI, diffing is best left to the proper tools.

Perhaps with a certain command a user-set diff command can be executed? Use Ctrl+Alt+[ and Ctrl+Alt+] (the automatic-backups back/forward hotkeys) to find the version you want to look at, and then hit a hotkey to open up in your own favorite diff viewer that version and the current version. That's pretty much perfect. My point is we don't need to rely on ST2 to diff for us.

I think this would be the perfect workflow: Use the back/forward hotkeys to traverse chronological history of current file, viewing each as a color coded incremental diff (use ST2's diff syntax, and python's diff lib). This allows us to see at each version what we did at that time. Once we find the one we're interested in we can issue an external diff viewer if we need to. I think its most likely we'll want to diff the one we're looking at with the current version. Changes can be made right then and there in the external diff viewer. Automatic-backups can also have a hotkey for rewinding to the one we're looking at (currently this is achieved by simply hitting save; if you change it to use a separate view this will need extra work).

As for disk use I was not indicating that you aren't making good use of space, I just was pointing out for myself that using two backup plugins simultaneously means i'm saving an extra copy of everything. It's never even gonna be a problem for me.

There are of course ways to improve disk usage with this kind of plugin though as I'm sure you're aware of... the changes can be saved incrementally (as generally the nature of editing files leaves the majority of it unchanged) and all backups can be compressed. I envision a sort of "doubly linked list" structure of compressed incremental changes, that will probably be very space-efficient. I can explain what I mean by this later (or if youre interested) but disk space really isn't an issue, and having direct access to the full state within the backup versions simplifies implementation of the plugin, so don't worry about it.

[joelpt]

The central "curved goes where" gutter can be omitted if we were to use Beyond Compare's approach as seen in those 2 screenshots in my previous comment. Instead of having curved connectors, we just collapse (fold) the appropriate amount of lines in each of the two views so that each pair of "equivalent" lines of text are literally next to each other. I actually think this approach is much better than the curved connectors because it makes it easier to quickly see what corresponds to what, and what changed between a pair of lines.

Regarding a user-set diff command, this is already supported with the Ctrl-Alt-M hotkey; see the README for details on setting the external program to execute.

I (briefly) considered writing incremental diffs as the backups, but given the relatively tiny size of text files it didn't seem worth the effort. And it's also nice, in a pinch, to be able to browse into the actual backups folder with a normal filebrowser and access the complete archive and pick files out from there. I find myself doing this from time to time when I have renamed/moved/deleted a file and Automatic Backups consequently cannot find the backups on its own.

[unphased]

Ah I hadn't realized the folding took care of alignment. What happens when we want to view (for instance) a big block that got added? Does the other side show empty space?

Ah yes the merge command should definitely handle it!! Excellent!!!

[joelpt]

Yep, the other side shows "empty" space: if you look at those screenshots of Beyond Compare, the "empty space" is shown with a crosshatched background. If I were to implement something like this in ST2, I would probably use a different background color or something for such "text absent" chunks.

[unphased]

Sounds great!

I definitely prefer this because the random warping that happens as you
scroll through the "dynamic" diff programs is VERY confusing. Those curvey
connectors look neat but actually just get in the way of productivity.

I think you can set up a custom syntax highlight style, I imagine since the
one for diffs can set blue and red background color we ought to be able to
accomplish this as well.

Good luck, I look forward to testing any new versions of this plugin!

On Sat, May 19, 2012 at 3:45 PM, Joel Thornton <
reply@reply.github.com

wrote:

Yep, the other side shows "empty" space: if you look at those screenshots
of Beyond Compare, the "empty space" is shown with a crosshatched
background. If I were to implement something like this in ST2, I would
probably use a different background color or something for such "text
absent" chunks.

---

Reply to this email directly or view it on GitHub:

#4 (comment)

[joelpt]

I agree about the curvy connectors; it takes extra time to trace them with your eyes to see what goes where. Having equivalent lines simply be on the same line is both simpler to implement and more productive.

The syntax highlight style is a good idea, I will think about that. I was originally thinking you'd want to retain the default syntax highlighting for the file and then just add blue/red background shading ... but that could run afoul of themes that are using a red or blue text color for certain elements. So the best approach may actually be to just switch to a syntax theme that uses "all white" text and colors modified text as "red". Though you would lose the syntax-specific coloring, you'd wind up with a view that makes it very easy to visually identify where the differences lie.

[unphased]

You're right about that. I hadn't even entertained the possibility of keeping existing syntax highlighting: I suspect the way to get this working could be difficult (at the very least probably requires extending all of the existing styles for each language with a diff-specific modifier), but if it's possible (perhaps use a very light red and light blue background color -- it'll be easy to avoid clashing with text colors) this would look absolutely phenomenal. It's definitely in the spirit of ST2.

[joelpt]

Agreed. I'm not very eager to go hacking all the themes for this; at that stage it really becomes something that should be getting implemented in ST2 itself. So if/when I do tackle this approach I will probably just go with using a couple different existing "common" color scheme scopes, and letting the user set them manually in the settings file if they don't like them.

More research is required to see if chunks of text in a view can have their background colors programatically modified on-the-fly (and entirely independent of the color scheme files), or failing that, if new color scheme scopes can be programatically injected on-the-fly without modifying said files.

The more I think about it though, the more I like the idea of just using one "white" color for all identical text and a different "red" color for all differences text. Look at those screenshots again; that is the approach taken by Beyond Compare and it makes it really easy to pick out the differences, especially when the differences are just a few characters in the middle of a given line.

[unphased]

The Beyond Compare approach looks really good. It would be an excellent starting point.

I mean I'd be completely happy with it.

So "starting point" is relative only to the extremes of what is possible.