Re: [PATCH] Support nvim as mergetool

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



pudinha <rogi@xxxxxxxxxxxxxxxxxxx> writes:

> ---
> 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?



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux