[PATCH] filemerge: support specfiying a python function to custom merge-tools

[Yuya Nishihara]

On Fri, 11 May 2018 12:05:50 -0600, Tom Hindle wrote:
> > I think it's better to pass parameters by variables (e.g. base=basepath),
> > instead of a packed argslist. In which case, we'll probably add a separate
> > function (e.g. _pymerge().)
> Sorry I don't understand this.

I meant the user merge function could take these variables as keyword
arguments just like hooks. e.g.

  def mymerge(ui, ..., *kwargs):
      kwargs['other']

> Aren't the args the merge tool / function receives entirely customizable?
> eg. I do this:
> --config "merge-tools.mymerge.args=the $base sat on $other $local mat"
> 
> How would we make a sensible arg name for each argument the user specifies?

So yeah, there are some impedance mismatch between [merge-tools] templates
designed for external commands and in-process hook-like functions. We could
make the in-process interface either:

 (a) like a command entry point, takes args built with the merge-tools.*.args
     template
 (b) a plain function, takes base, other, etc. as parameters.

(b) is more similar to the other extension APIs, but wouldn't work well with
the [merge-tools] syntax which has the .args= field. I'm not sure which is
better.

> >> +    if toolpath and procutil.shellsplit(toolpath)[0].startswith('python:'):
> > Perhaps shellsplit() shouldn't be applied as 'python:' isn't a shell command.
> 
> _picktool returns a quoted 'toolpath' (using 
> procutil.shellquote(toolpath)), so this was just to undo that.
> 
> I could do one of these:
> a. leave it as it is
> b. just strip off the quotes manually (but this doesn't seem a good 
> idea, as I would have to deal with shell differences)
> c. change _picktool to not call procutil.shellquote() on toolpath when 
> it starts with :python

Maybe (c) because _picktool() returns internal tools unquoted. The "python:"
syntax seems more like internal names than command names.