Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Splits managing in Vim [closed]

Tags:

vim

macvim

Working on a big and medium sized project I often end up with lots of splits on my screen as well as several tabs opened with 5-6 splits in each. Usually I use different tabs for different directories and logical workspaces to separate the work on feature A from the work on feature B or bug C and my notes.

enter image description here

Managing this madness becomes a problem when you have a lot of additional splits from plugins such as NERDTree, Fugitive, Gundo and many others who like to take additional splits. After such helper split opens and closes the whole set up has a change of distortion in height and width. I mean, some windows become to small, some become larger than they were initially (and I manually have to adjust their height and width with CTRL+W > and CTRL+W < and friends.

Usually it's faster to do resize every split with mouse but it's not even close to the Vim way.

Sometimes I even want to swap some splits or move on split to the right. CTRL+W HJKL don't always help as they kick splits too far and distort sizes again. Rotation CTRL+W r works only on simple cases.

How do you manage lots of buffers, splits, and tabs?

Edit: I see there are votes for closing. The question might seem too general to you, so there is a more concrete one: what is a good workflow of working with lots of buffers and splits? (One of the answers is to promote splits to separate tabs when it needs more space)

like image 341
imslavko Avatar asked Aug 16 '13 18:08

imslavko


4 Answers

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".

like image 100
romainl Avatar answered Oct 17 '22 22:10

romainl


Splits, or windows, as they are usually called, are fragile.

  • When you delete a buffer, the other buffers are not affected.
  • When you close a tab page, the other tabs are not affected.
  • When you close a window, your entire window layout gets messed up in unpredictable ways, requiring tedious rearrangement (which is difficult and inconvenient to do in Vim), over and over again.

Therefore I would advise against a workflow centered around windows in Vim.

My advice: Keep the number of windows in the current tab page small. Use windows in a focused manner and only for certain uses (looking at different parts of a file, diffing files, header/implementation files, ...). Use tab pages for workspaces. Get comfortable with the many other means of navigating buffers: the buffer list, :find and the :edit family, fuzzy finder plugins, file explorers, etc.

like image 29
glts Avatar answered Oct 17 '22 21:10

glts


Try ctrl-w <N> > to change size by N at once. In case you don't do that yet.

I myself prefer having stuff in tabs instead. And ctrl-w shift-t to move a split to a separate tab.

like image 28
aragaer Avatar answered Oct 17 '22 22:10

aragaer


How about using more GNU screen or tmux? Just windows in vim won't help you much, same for just using more consoles.

With screen you can save sessions, as well in vim with :mks.

And in vim rebind ctrl+w,h/j/k/l to just ctrl+h/j/k/l! Also shortcuts for maximizing vertically, maximising horizontally and making all windows equally sized help. For resizing I also have shortcuts, but mostly I work with fullsizing/resizing all, window management is not the best feature of vim, without a mouse it is even worse.

Excerpt from my .vimrc:

" WINDOW MANAGEMENT SETTINGS

"moving from window to window
nnoremap <C-h>  <C-w>h
nnoremap <C-j>  <C-w>j
nnoremap <C-k>  <C-w>k
nnoremap <C-l>  <C-w>l

"open new blank file
nnoremap o<C-h> :lefta vsp new<cr>
nnoremap o<C-j> :bel sp new<cr>
nnoremap o<C-k> :abo sp new<cr>
nnoremap o<C-l> :rightb vsp new<cr>

"move window
nnoremap <Leader><C-h> <C-W>H
nnoremap <Leader><C-j> <C-W>J
nnoremap <Leader><C-k> <C-W>K
nnoremap <Leader><C-l> <C-W>L

"maximise horizontally
map <Leader>= <C-w><Bar>

"maximise vertically
map <Leader>- <C-w>_

"make all windows equally sized
map <Leader><Leader> <C-w>=

"change windowsizes in visual mode
"horizontally - always three chars else it takes ages
vnoremap - 3<C-w><
vnoremap = 3<C-w>>

"vertically - always three chars else it takes ages
vnoremap _ 3<C-w>-
vnoremap + 3<C-w>+

"moving from window to window in visual mode
"that way you can move from window to window and resize with -,=,_,+ directly as needed
vnoremap <C-h> <ESC><C-w>hv
vnoremap <C-j> <ESC><C-w>jv
vnoremap <C-k> <ESC><C-w>kv
vnoremap <C-l> <ESC><C-w>lv

For NERDtree I show the window and close it again. Since something is bugged with it, I open it and resize it to a fixed width automatically:

nnoremap <Leader><CR> :NERDTreeFind<CR>999<C-w><40<C-w>>010l
like image 1
sjas Avatar answered Oct 17 '22 23:10

sjas