I use http://meldmerge.org and besides syntax coloring it has filters for comments and whitespace, a 3 way file compare and folder compare that is very useful to see changes between code updates.
So much time would be saved if ppl did a google search before writing tools :) (its fine to reimplement, test, learn etc. But sometimes I really wonder ;)
Before I wrote this, back in 2009 [1], I looked for existing tools that would do this already. I found colordiff and cdiff, but neither of them would highlight the parts of lines that had changed. Not finding anything that did what I wanted, I wrote something.
You would think that would be a solution, but sometimes learning to use a tool is about as hard as writing the tool yourself. (And in a few special cases, it's even more difficult!)
Not that this applies here, but it is something to consider.
Edit: It also pains me that this is not the default (or one of the two default) diff views almost anywhere. The best diff I've used was in Phabricator. But Google, Github and Git don't have a support for side-by-side diffs, which I'd argue are the best view in 90% of incremental changes.
Hmm, seems I was overly optimistic. This fails with two words only on one line, highlights the words "red" and "blue" as being composed of each other and so on. Back to
Sorry, could you give an example input icdiff performs poorly on? I just tried it on "red" and "blue", and got http://www.jefftk.com/icdiff-red-blue-2x.png which seems pretty reasonable to me.
Very cool! I love tools that provide better UX around diff - that show not just the shortest possible edit script, but a more human-readable output of what has actually changed. I've been prototyping some ideas in a web app: http://diff.so.
This is a great tool. I work on Unix (without X) from Windows and so often have to ftp files about just to use Meld, which is my usual preferred diff tool.
But I can use icdiff in a PuTTY session with a coloured xterm and get a sensible and clear diff comparison.
I enjoy using console vimdiff in PuTTY, because my configuration allows quick navigation without too much thought.
The accumulated time for starting vim can become annoying when iterating over many files. (I could investigate loading diff pairs into tabs if I was sufficiently bothered.)
Helpful .vimrc settings:-
Firstly, map some keys to navigate to preceding/successive differences...
" Next/ previous diff (analogous to j/k, use the same fingers)
nmap <F6> ]czt
nmap <F7> [czt
And some helper keys...
" Diff update, i.e. repaint the screen when needed
nmap <F5> :diffupdate<CR>
" Get from Buffer 1/ 2/ 3/ 4
nmap <F1> :diffget 1<CR>
nmap <F2> :diffget 2<CR>
nmap <F3> :diffget 3<CR>
nmap <F4> :diffget 4<CR>
Configure all visible windows when starting via vimdiff or diffthis. I prefer no folding (for added context) and then to navigate with the above keys.
" Apply window-local settings to all diff windows
au! FilterWritePost * if &diff | set wrap | set foldcolumn=0 | set nofoldenable | endif
It costs a few bucks but BeyondCompare http://www.scootersoftware.com/ is the best differ I've used. It's not terminal based, but is supported on Windows, Mac, and Linux.
I would suggest highlighting the line that changed as well, with a subtle background color.
I mostly use GitGutter, a Sublime Text plugin that puts a symbol in the "gutter" (line numbers column) to indicate which lines changed, where one was deleted or where one was added. It works only on git repositories, though.
Unfortunately "subtle" isn't really an option when working with standard terminal colors. There are only eight colors, and on most terminals it would be fair to describe all of them as "garish".
It's just coloring the standard diff output so lines starting with > or + are yellow and ones starting with < or - are green. This is also what "git diff" does by default: http://www.jefftk.com/git-diff-color-2x.png
diff -y is side-by-side. As far as I know colordiff does per-line coloring, while icdiff seems to have finer granularity. This dude really should have patched colordiff, though. Or just used emacs.
colordiff is just a perl script to colorize diff's output. Patching it to add support for the kind of coloring I want to do here would be a lot of work.
As for using emacs, there are many cases when I want a stand-alone diff tool.