[PATCH V3] extdiff: add --per-file and --confirm options

[Yuya Nishihara]

On Fri, 01 Feb 2019 22:58:54 -0800, Ludovic Chabant wrote:
> > My idea is basically as follows:
> > 
> >   if cmd and opts found in extdiff:
> >       # it must be a user-defined tool
> >       look for extdiff.gui.<cmd>
> >   elif cmd.diffargs found in diff-tools:
> >       # perhaps it's a stock tool template defined in [diff-tools] (less common)
> >       look for diff-tools.<cmd>.gui
> >   elif cmd.diffargs found in merge-tools:
> >       # perhaps it's a stock tool template defined in [merge-tools] (common)
> >       look for merge-tools.<cmd>.gui
> 
> In practice (again, after a bit of testing), I got confused again pretty easily. For instance:
> 
> [extdiff]
> blah =
> gui.blah = True
> 
> ...doesn't do what I would expect. If "blah" is *not* a stock tool, and is in my $PATH, it would default to calling "blah $parent1 $child", but the GUI flag would be False because we didn't find any diff options per se.
> 
> Alternatively, if "blah" *is* one of the stock tools, I can do:
> 
> [extdiff]
> blah = /path/to/blah
> gui.blah = True
> 
> This would override the path from the stock tools (while still using the stock tool arguments), but wouldn't override the GUI flag, which seems inconsistent. The same problem (inconsistent overriding) happens if I use "cmd.blah" instead of "blah".
> 
> So far, something that feels vaguely intuitive to me would be:
> 
>   (1) get "gui.<cmd>" from [extdiff]
>   (2) if we have to check [diff-tools] and/or [merge-tools] to find arguments:
>           if we didn't find any setting at step (1):
>                   check "<cmd>.gui" in the same section we found the arguments
>   (3) fall back to False if nothing is found.

That sounds good to me.

Suppose we'll introduce a core "extdiff" command, we can also make it a
core-specific feature. (i.e. no "extdiff.gui.<cmd>" since the core extdiff
command won't look for tools in [extdiff] section.)