[MERGE] Implement a --diff-command option for bzr diff.

[Stephen Ward]

On Wednesday 29 August 2007 06:26:26 am Nicholas Allen wrote:
> I agree. But I was saying that it makes sense to have *both* the code
> approach and flexible commands. With the flexible commands you have the
> disadvantage that it will invoke the command for every file that changed
> but in many cases this is ok. If not then you are right the code
> approach is better. Just because the flexible command cannot satisfy
> every single use case does not mean it would not be a useful feature to
> have as well. 

I've never been fond of unnecessary redundancy in tools, so I'm a little 
biased in favor of the more general mechanism.  But I understand that other 
people may have different preferences.

> There are many graphical file diff viewers that just take 
> 2 file names as arguments and all of these could then be easily
> supported by bzr without any extra code. I don't think it is reasonable
> to expect bzr to have special code for every diff viewer that exists or
> will exist in the future.

I agree, it is not reasonable to *require* that bzr have special code for 
every conceivable diff viewer.  But that is irrelevant, because the difftools 
plugin does not require that today either.  This is the sum total of 
tool-specific code in the plugin:

register_diff_tool(TreeDiffTool('fldiff'))
register_diff_tool(ListDiffTool('gvim', diff_options='-f -d'))
register_diff_tool(ListDiffTool('gvimdiff', diff_options='-f'))
register_diff_tool(TreeDiffTool('kdiff3'))
register_diff_tool(TreeDiffTool('kompare'))
register_diff_tool(TreeDiffTool('meld'))
register_diff_tool(ListDiffTool('mgdiff'))
register_diff_tool(TreeDiffTool('opendiff', cleanup=False))
register_diff_tool(ListDiffTool('tkdiff'))
register_diff_tool(ListDiffTool('vim', diff_options='-d'))
register_diff_tool(ListDiffTool('vimdiff'))
register_diff_tool(TreeDiffTool('xxdiff', diff_options='--exclude=.bzr*'))

So far, all the diff tools fit into one of two broad classes (recursive tree 
or iterative list), and the members of these two classes also share the same 
preferences as far as argument order (probably for historical reasons).

The default, if the plugin is given an unknown diff tool, is to treat it as a 
TreeDiffTool with no special options (this means, for example, that the 
registration step for 'meld' and 'kompare' is not really needed).  This seems 
to work fine, for most existing tools.

The main case where I could see a command pattern being necessary is for a 
hypothetical tool that required named arguments rather than positional ones, 
e.g. "mytool --old %FROM --new %TO".  But so far, this has not come up.

-- Steve