Basically, if you have multiple split windows, it allows you to do a cmd+O to zoom the current split view (i.e. making it the only view visible). That's neat if there's something tricky going on (say a weird bug) and you want to focus just on this piece of code, without seeing anything else. Once you're done, you can hit cmd+O again, and your old split setup comes back. I love this plugin.
Any advantage to this plugin over mapping one key to ':tabopen' and another to ':tabclose %'? I have this in my .vimrc and it seems to get the same results:
Edit re below: OK, good point. But I would still prefer the plugin (and plan to install it) because I just don't use tabs, preferring to stick with splits.
I already have a fixed set of tabs open for different use cases, and switch between them frequently. Adding a new tab to that temporarily would probably confuse me. I may try the tabedit / tabclose solution nevertheless though, I hadn't thought about doing it that way. The advantage being that I'd have one plugin less :)
I have mapped the Tab key to move between split windows. I also mapped Ctrl+T to open a new tab, and CTRL-H and CTRL-L to move to the left/right tab respectively. It works well and seem pretty natural. I suppose if I had a giant monitor I could use more splits, but realistically more than two of them feels very cramped. My .vimrc is here: https://raw.github.com/ipartola/ipartola-bash-and-vim/master...
Which does both split navigation and split maximizing. I could probably switch to tabs but I'm happy with how things work and I don't really see any advantage over how I'm doing things now.
Awesome (another tiling WM), tmux with panes, and vim with windows gives me three layers of organization. Really great if you are into self-imposed structure.
After years of abusing my little finger for using Ctrl & the RSI that goes with it, I tend to use alt/meta with my thumb more and more nowadays, for this I make it usable in insert mode also, this is probably one of the oldest bits of my .vimrc
It might not work the way you prefer using your favorite input method, but vim allows you to enter any utf-8 character, and even has mnemonic digraphs for many you are most likely to want. To get è, for example, in input mode just type <ctl>-k`e.
The point of my comment is that with an imap on <a-j>, you can't input the character ê because it will trigger the mapping. This includes option+i, e on OS X.
I moved over to evil-mode (Vim emulation) in Emacs a couple of months ago and do most things the Vim way but some things are more efficient to do in a non-Vim manner and this is one of them.
Although I use M-- and M-| for vertical and horizontal splits.
+1 For evil-mode. I'm still using MacVim and Emacs+Evil side by side because many things that my vim does (via plugins etc) my emacs/evil doesn't do yet and I lack the time to research it all. But having elisp for extension is such a joy to use. I've dabbled a bit with evil, too, and I really like how easy it is to extend it.
Funny, I just started using evil too. You might want to checkout prelude/projectile if you haven't yet. Also, less obviously for a vimmer, keychord.el. I'm able to use 'jk' for ESC, for instance. For others interested, the brief evil manual is worth peeking at: https://gitorious.org/evil/evil/blobs/raw/doc/doc/evil.pdf. Motions, text objects, and operators in theory are easy to add in elisp, which is cool. For this reason, evil seems unlike other vim 'emulators' that I'm aware of (could just be ignorance, obviously). I'm really digging evil though.
Yes, I feel similar. I've tried way too many vim 'emulators', and the only other one which comes close to that 'vim' feeling is XVim for XCode. However, neither that one, nor all the others feel as easily extendable (with the exception of Vico, a native Mac vim clone that uses Nu (a cocoa lisp) for extension, but Vico even though it's easily extendable lacks a ton of vim commands)
As someone who's been using vim for about 20 years, here are the problems I have with any vi/vim emulation modes in emacs:
* Configuring emacs still requires learning a lot about emacs (which takes a lot of time).
* These vi/vim emulation modes doen't touch SLIME's keybindings, afaik. So, to make them less finger-twisting will require manual rebinding (which takes yet more time).
* Most emacs tutorials assume you're using the standard key bindings. So you still have to learn them.
All of the above make the various vi/vim emulation modes fine for people who already know emacs, or who are willing to sink a ton of time in learning it and reconfiguring it. But they are far less attractive to vim users who already have a nice environment set up in vim and feel comfortable in it.
I guess they're still better than nothing. If I had to use emacs, I'd certainly use something like evil mode. But evil mode alone is not enough to make a vim veteran feel comfortable in emacs.
I have somewhat similar, though I map the <C-w>hjkl keys to just the arrow keys themselves with no modifiers. The only problem is when other people are poking around at one of my vim sessions it trips them up.
Mastering window splitting and tabbing allows one to truly step into the flow that Vim has to offer. However, it doesn't stop at simply dealing with opening files in new panes.
:vsplit .
I use this all the time when I need to find a file or I'm not sure where something is. It just opens the file browser in a new window split. It's extremely handy. Once you've got it open, it's important to note that you can use your regular commands in the file browser as you would in Vim.
/beginning of file name
This allows for a really nice and fast file browsing experience like when you're searching through code. I prefer it much over cd'ing around on the command line. I can see the directory or file I need to go to, type /, the first few letters, and hit enter.
vim .
From the command line, you can simply open Vim as a file browser and use it to browse around your project. I do this to get projects in my head sometimes when I know I'm going to be dealing with multiple parts of the system at once. I can browse around a bit and get things open in tabs or splits and go to town.
set autochdir
This is a handy configurable I wish I would've picked up a long time ago that, in my opinion, perfectly accents heavily using filesystem browsing in Vim. If you're someone that splits or tabs around a lot in Vim, this is a really handy change. Instead of your directory always staying relative to the first file you opened, the directory changes depending on what file you're working with.
This means you can do something like:
:vsplit ../../models/foo.php
And when you're working in foo.php, you realize you need to make a change to the bar model, bar.php, you can simply do:
:vsplit bar.php
Instead of having to do:
:vsplit ../../models/bar.php
Going beyond filesystem awesomeness with Vim and window management, you can also use it to easily create new files as you're going along. This is particularly useful for new projects where you're flowing along generating new models. Working on a model and suddenly realize you need to create another one?
:vsplit newfilename.php
This will create the new file in your buffer and you can start typing. If you realize you made a mistake, simply close the pane without writing at the file will have never been written. This can also be handy when you need to type something out or keep quick notes. Have a little pane off to the side with notes about what you're working on. Maybe it's some numbers you need to keep in your head or maybe someone interrupted you with a request while you were knee-deep in terminal land.
Can you point me to docs on in file searching? Those symbols are predictably hard to google. Based on a little messing around, it appears that * is what I expect from bash, and can also include directory separators.
I used to use splits, then I used tabs + splits, now I just use buffers. The only time splits come into it are for quickfix or diffs. Just get used to buffers. Lots of vim commands will work with buffers but not with splits or tabs.
People new to vim will immediately jump on splits or tabs because of how their previous editor work flow worked, but you aren't going to unlock the full power of vim until you get used to buffers.
I agree with regard to tabs, but I always felt like buffers were orthogonal to splits. I use both all of the time. Buffers to manage a working set of files and splits to manage the files that I want to viewable. I frequently find myself using splits to write new code while referencing other parts of the code base (or even the same file).
Same here, I can quickly have all the functions, data, and docs visible, that I need for the particular code that I'm currently writing. Having to switch back and forth would only confuse me.
Usually, the biggest problem I have with other IDEs is that they don't allow me to split as freely as vim / emacs do. XCode is shockingly stupid about it, for example.
My work session has about a hundred or two "open" files in the buffer, and I split and un-split windows often so that I can view multiple files at once.
But my most common way to change current file is :b <first few letters + tab complete>
I occasionally prune my buffers for files that have been deleted, but it's mostly unnecessary to. When I close it, I just save the session in a file and re-open the session.
My happiest thing lately is to use NERDtree and then on selecting a bookmark, folder or file to then hit t to open that in a new tab.
So I have tabs and those are then split. Each subject of work or exploration has a tab with a few splits. I end up with much less clutter than sublime text. Easy to close out a tab.
If you use splits a lot, you might be interested in the Golden Ratio plugin. It resizes the active window to be about (user-definable) two-thirds of the screen. So you jump between windows and get max screen space for the one you're working on.
Sometimes you don't want it, so you can toggle it off.
67 comments
[ 2.4 ms ] story [ 137 ms ] threadhttps://github.com/skeept/dotvim/blob/master/plugin/ZoomWinP...
Basically, if you have multiple split windows, it allows you to do a cmd+O to zoom the current split view (i.e. making it the only view visible). That's neat if there's something tricky going on (say a weird bug) and you want to focus just on this piece of code, without seeing anything else. Once you're done, you can hit cmd+O again, and your old split setup comes back. I love this plugin.
Edit re below: OK, good point. But I would still prefer the plugin (and plan to install it) because I just don't use tabs, preferring to stick with splits.
Open your split as a new tab. The new tab (i.e. that split) takes up all of vim. When you want to return to your splits, just close that tab.
au VimResized * wincmd =
The relevant parts are:
http://www.vim.org/scripts/script.php?script_id=4186
I'd also suggest using <C-o> instead of the <Esc>...i dance.
Edit: "The way [Vim] stores alt+letter in its input queue collides with UTF-8/Unicode handling" -- LeoNerd in freenode/#vim at 2013-04-15 15:22:29
It might not work the way you prefer using your favorite input method, but vim allows you to enter any utf-8 character, and even has mnemonic digraphs for many you are most likely to want. To get è, for example, in input mode just type <ctl>-k`e.
Obviously not very helpful to people not on a Mac, but I don't have to go through Alt mappings at all.
Although I use M-- and M-| for vertical and horizontal splits.
* Configuring emacs still requires learning a lot about emacs (which takes a lot of time).
* These vi/vim emulation modes doen't touch SLIME's keybindings, afaik. So, to make them less finger-twisting will require manual rebinding (which takes yet more time).
* Most emacs tutorials assume you're using the standard key bindings. So you still have to learn them.
All of the above make the various vi/vim emulation modes fine for people who already know emacs, or who are willing to sink a ton of time in learning it and reconfiguring it. But they are far less attractive to vim users who already have a nice environment set up in vim and feel comfortable in it.
I guess they're still better than nothing. If I had to use emacs, I'd certainly use something like evil mode. But evil mode alone is not enough to make a vim veteran feel comfortable in emacs.
Vim emulation modes are mostly for people who prefer a certain environment, like f.e. Emacs but want more efficient keybindings.
HTH
This means you can do something like:
And when you're working in foo.php, you realize you need to make a change to the bar model, bar.php, you can simply do: Instead of having to do: Going beyond filesystem awesomeness with Vim and window management, you can also use it to easily create new files as you're going along. This is particularly useful for new projects where you're flowing along generating new models. Working on a model and suddenly realize you need to create another one? This will create the new file in your buffer and you can start typing. If you realize you made a mistake, simply close the pane without writing at the file will have never been written. This can also be handy when you need to type something out or keep quick notes. Have a little pane off to the side with notes about what you're working on. Maybe it's some numbers you need to keep in your head or maybe someone interrupted you with a request while you were knee-deep in terminal land. Let Vim be your flow and your editor.`set autochdir` is very nice. Thanks for sharing!
Also, depending on how you like to work, keeping a stable working directory can be very useful:
is somehow less mentally taxing than:" uses expression to extract path from current file's path
map <leader>e :e <C-R>=expand("%:p:h") . '/'<CR><C-M>
map <leader>s :split <C-R>=expand("%:p:h") . '/'<CR><C-M>
map <leader>v :vnew <C-R>=expand("%:p:h") . '/'<CR><C-M>
People new to vim will immediately jump on splits or tabs because of how their previous editor work flow worked, but you aren't going to unlock the full power of vim until you get used to buffers.
:b# last buffer used
:b num Switch to various buffers by number
:buffers See a list of buffers
:bd delete buffer
^^ map those to keys
cntrlp for easy buffer switching and opening: https://github.com/kien/ctrlp.vim
My work session has about a hundred or two "open" files in the buffer, and I split and un-split windows often so that I can view multiple files at once.
But my most common way to change current file is :b <first few letters + tab complete>
I occasionally prune my buffers for files that have been deleted, but it's mostly unnecessary to. When I close it, I just save the session in a file and re-open the session.
C-w C-w
This moves to the last used split, i.e. it's a quick way to jump between two.
So I have tabs and those are then split. Each subject of work or exploration has a tab with a few splits. I end up with much less clutter than sublime text. Easy to close out a tab.
Also ctrl-w v is my favorite way to split.
Sometimes you don't want it, so you can toggle it off.
http://www.vim.org/scripts/script.php?script_id=3690