Re: [PATCH] Support nvim as mergetool

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 18, 2020, 20:30 UTC
Message-ID: <xmqqd04sbm6n.fsf@gitster.c.googlers.com>
In-Reply-To: <20200718192001.27434-1-rogi@skylittlesystem.org>

pudinha <rogi@skylittlesystem.org> writes:

Show 5 quoted lines

> ---
> Hello giters! Hope you are well!
>
> I made this little patch to support nvim as a merge tool. What do you
> think?

Uninspiring.

But that is not your fault.

The way vimdiff, vimdiff2 and vimdiff3 waste one file for each just to have a different name is simply bad, and the way it was extended to cover gvimdiff family is even more horrible. This patch makes the existing mess even worse. That part is your fault, I'd have to say.

I'd rather see us explore ways to improve the current arrangement used to support these 6 variants before adding yet another 3 new ones.

For example, we could add another method the backends could define, call it list_tool_variants, and whenever the control flow goes from run_merge_tool through setup_tool for a tool whose name ends with [1-9], e.g. "foomerge3", we first see if there is "foomerge" tool and if there is ask it if it knows about "foomerge3" variant by calling its list_tool_variants.

That way, we probably can remove the files for vimdiff2, vimdiff3, gvimdiff2 and gvimdiff3 (gvimdiff needs to stay there, as we do not want to make the name derivation rule too complex) only to hold a single line ". vimdiff". Then the next person who adds yet another set of backends based on a yet another reimplementation or skin of vim would only have to add a single file in mergetools/ directory, not three.

Hmm?