Not quite true though, but again it's speed related (and this is very apparent in C++ projects). It has benefits when compiling a changed file. The smaller your file and the fewer things you include, the faster you can compile it and link it with the other (unchanged) objects.
What about source control, concurrent team work, external libraries, etc.?
"sections" take care of that.
The "one big file" gets processed so that each section is kept in sync with a file.
Again: the idea is about make editing easier, it's an addition, your "one big file" is just a compound "view" over atomic files.
I too like to have code from multiple logical sections of my projects visible on the same screen at times.
Splitting windows in vim works nicely for this purpose.
I can see how that would be useful, but I have a question. If you do edits in both windows, how do you save them? Do you just save in one window and reload the other?
In vim, when you have the same file open in different windows any changes immediately appear in the other window. They are the same buffer, there are just two windows to it.
You can see this by opening a file, and hitting "<Ctrl-W> <Ctrl-S>" to split the window. Do some editing and you'll see it in both places. ":ls" will show only one buffer. And if you have display of the buffer state visible, when you ":w" all the windows will update to say they were saved.
The true reason is purely historical.
Editor where just TOO SLOW to handle big files (on DOS they often were limited to 64kb, if not less)
Please note that I love "modular code", hence the notion of "sections" in my big file.
To clarify: I love to edit one big file, but for other purposes I definitely need small ones.
What I am basically proposing is that it is easier to edit multiple files from within a single window/buffer. But there exist no editors that do that AFAIK
I am not the only one, see this Python tool for Vim: http://coliveira.net/software/editing-multiple-files-in-a-si...