What is the logic behind limiting the diff buffer count to 4?

[Nirk Niggler]

From structs.h:

# define DB_COUNT 4 /* up to four buffers can be diff'ed */

Is there a compelling reason to keeping the limit at 4 rather than upping it to a limit like 9?

[LCD 47]

DB_COUNT doesn't mean what you think it does. At most four buffers
are used when diff-ing two files: file1, file2, a common anmcestor, and
the result of a merge.

/lcd

[ZyX]

I do not know reason for 4 (though @LCD 47 suggested the one that makes sense), but what is the reason for limit equal to 9? I you want to raise it you must explain why.

[Charles Campbell]

I recompiled vim with a DB_COUNT of 5, and that successfully worked to
diff five files. I suspect that the DB_COUNT limit can be raised
without difficulty. I suspect that with a bit of coding that the
DB_COUNT could be made arbitrary (ie. dependent upon how many files are
being requested for simultaneous diffing).

Regards,
Chip Campbell

[ZyX]

> I recompiled vim with a DB_COUNT of 5, and that successfully worked to
> diff five files. I suspect that the DB_COUNT limit can be raised
> without difficulty. I suspect that with a bit of coding that the
> DB_COUNT could be made arbitrary (ie. dependent upon how many files are
> being requested for simultaneous diffing).

Absence of limit makes sense. Both 9 and 4 look like some magic number. 4 was questioned by OP, I just added a question for 9.

I do not think though somebody is going to bother with memory (de)allocation implied by removing the limit. But before increasing limit to 9, 99 or INT_MAX one has to answer why. I do not see much difference between 4 and 9: I never actually needed more then 3; and even 3 diffed buffers are a bit confusing. Thus I would like to hear a use-case that resulted in request to increase the limit.

[Nirk Niggler]

9 was a pretty arbitrary number, but here's a somewhat standard use-case for 5: git rebase --onto (http://git-scm.com/book/en/Git-Branching-Rebasing#More-Interesting-Rebases)  It involves 5 files: branch A, common ancestor of A and branch C, branch B, common ancestor of branch B and branch C, and the result of the merge

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to a topic in the Google Groups "vim_dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/2jOKa087Oic/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Marius Gedminas]

I've once needed to diff five[*] very similar files[**]. I had to
rebuild vim after increasing that arbitrary limit, and then vimdiff
worked just fine.

[*] probably five, I don't remember the exact number, only that it was
more than vim's default limit
[**] they contained names of installed Debian packages from five
different computers, one per line

Marius Gedminas
--
The laser etcher can accept most any image data, (think logos or screen dumps!)
and render it on a heat-sensitive surface. There's a big tunable exhaust fan,
so the thing can be dialed in to Not vaporize your laptop.
-- Stuart Kreitman

[Tony Mechelynck]

On 02/11/13 14:26, Marius Gedminas wrote:
> On Fri, Nov 01, 2013 at 07:50:58AM -0700, ZyX wrote:
>>> I recompiled vim with a DB_COUNT of 5, and that successfully worked to
>>> diff five files. I suspect that the DB_COUNT limit can be raised
>>> without difficulty. I suspect that with a bit of coding that the
>>> DB_COUNT could be made arbitrary (ie. dependent upon how many files are
>>> being requested for simultaneous diffing).
>>
>> Absence of limit makes sense. Both 9 and 4 look like some magic
>> number. 4 was questioned by OP, I just added a question for 9.
>>
>> I do not think though somebody is going to bother with memory
>> (de)allocation implied by removing the limit. But before increasing
>> limit to 9, 99 or INT_MAX one has to answer why. I do not see much
>> difference between 4 and 9: I never actually needed more then 3; and
>> even 3 diffed buffers are a bit confusing. Thus I would like to hear a
>> use-case that resulted in request to increase the limit.
>
> I've once needed to diff five[*] very similar files[**]. I had to
> rebuild vim after increasing that arbitrary limit, and then vimdiff
> worked just fine.
>
> [*] probably five, I don't remember the exact number, only that it was
> more than vim's default limit
> [**] they contained names of installed Debian packages from five
> different computers, one per line
>
> Marius Gedminas
>

Two is extremely common. Three or four (with common ancestor and/or
common descendant) are not unheard of. You showed a usecase for five,
and by analysing that usecase, it may be inferred that six or seven
should be possible, but that 100 would be too many to be expected in
practice. I suppose that exactly where to fix the limit leaves some room
for appreciation. Maybe it could be made into a compile-time option,
either hidden in src/feature.h (that would be a simple matter, moving
its define line from line 1731 of src/structs.h to some place in
src/feature.h where FEAT_DIFF is known to be defined, maybe between
lines 474 and 475; feature.h would then need to be #include'd in
structs.h (where it isn't; diff.c includes it via vim.h); or it could
even be added as a new configure argument, maybe something like
--with-diff-count=7 (the default remaining 4, I suppose) (but that would
mean delving into the configure scripts, which is something beyond my ken)..

Of course the maximum number should be "safely lower" than the maximum
number of file handles on the system where Vim is running, and by safely
I mean: so that neither Vim nor other programs running in parallel would
be made to run out of file handles.

My Mercurial configuration contains settings for quite a number of
external merge tools; I'm not sure where they all came from. Those for
Vim (unsurprisingly, I suppose) set four arguments but immediately
closes the last two buffers. I attached the relevant lines from the
output of "hg showconfig", after sorting, and with the Vim lines
repeated at the end. As you can see, none of the examples are for more
than 4 files. (By comparison to hgrc files, the part until the first dot
is the [section] name.)

But of course the capabilities of vimdiff must not be kept down to what
existing version-control software is known to require.


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
39. You move into a new house and decide to Netscape before you landscape.