I use splits only when I really need to have two files side by side (because one is used as a reference, usually, HTML - CSS for example). Otherwise, I just use regular buffers loaded in a single window. I also don't use nerdtree or anything that would take up too much space.
I try to avoid navigating between files: tags are a much better way to go.
My vim is pretty much always a large gray rectangle.
EDIT
Working with multiple "things" has always been a hard problem to handle. More so when we try to deal with many of those "things" at the same time and in the same space. It's a hard problem because we are incapable of dealing with more than a few things concurrently: our mind is not optimized for that. This is why the Memory game is not as easy as it looks, why we can't remember shit after a Powerpoint slideshow full of lists and graphs and why people die with a phone in one hand and their driving wheel in the other.
Because we can't work on 4 buffers at the same time, split windows should be reserved to situations where actual work is done in one window and the other window is used for reference (documentation, an HTML document when doing CSS…) or for feedback (linting, calculation results…). In such a setup, the only part of the body that switches to the other window is our eyes: we don't need keyboard shortcuts or the mouse.
But we love to make our lives more complicated than necessary. We love to think of ourselves as multitasking gods so we split windows, we put windows in windows in windows and we must find fragile hacks for managing all that mess. Keyboard shortcuts are not a valid solution for various reasons and we hate the mouse, right?
Anyway, the basic problem with split windows is the same as with regular buffers and tabs: in order to work on buffer #3, we must switch to buffer #3. Whether buffer #3 is hidden, displayed in the top right window or in another tab is irrelevant, we must hit a few keys to get to it. When the target buffer is hidden, we do :b3
to show it. When it is in the top right window, we play with <C-w>…
mappings, default or custom. When it is in another tab we tend to do gt
until we find it (or :sb3
which is a lot smarter). Whatever spatial setup we choose, we still have to switch to the target.
A problem that only concerns the kind of layout that you are using is that you must think and move in two dimensions. Jumping from the bottom left window to the top right window is not really linear (unless you use <C-w>w
) and requires far more thinking and typing than simply taking a look at that window.
Another problem is how the workspace is divided and the consequences it has on the number of buffers you can deal with and the size of their windows.
All in all, my opinion is that the best way to deal with multiple buffers is to leave windows and tabs alone and find a leaner workflow.
Regular buffers can be tricky, too: the way you can have a 1,2,5,7
list is weird in its own way. But I believe buffer-switching (as opposed to window-switching) is fundamentally more intuitive and solid.
:bn "show next buffer in the list
:bp "show previous buffer in the list
:b3 "show buffer #3
:bf "show first buffer in the list
:bl "show last buffer in the list
:b <tab> "select buffer from a menu
:b fo<Tab> "select buffer from a menu
:b foo "show buffer named foo
The following mapping makes switching buffers a piece of cake, but you can also try the many buffer-switching plugins available.
nnoremap gb :buffers<CR>:b<Space>
My prefered navigation method is not buffer-based, though. Nowadays, I find it a lot easier to actually forget the file structure of the project all together and use tags. When I navigate around, I move to a specific class or a specific method or a specific array or whatever. My workspace is just one window, showing 1 of 15 or 20 buffers and I have no NERDTree, no tabs, no MiniBufExplorer, no TagList… since switching to another buffer requires at least a few key presses anyway I don't see any valid reason for slicing and dicing my workspace.
Because I don't put myself in a corner with fancy over-complicated gyzmos, I don't have to waste my precious time looking for workaround to workarounds and I can safely laugh at the latest batch of image macros. Wait, I meant "work".