At work, I usually have at least two windows open at all times: Vim full-screen on one monitor, a terminal full-screen on the other—or sometimes one terminal taking up most of the screen and another smaller terminal tailing a logfile. The Vim window gets used for editing (of course), the terminal is used for running test suites and exploring the codebase and finding and opening files in Vim. The reason I've never felt the need for a file-browser plugin in Vim is because I've always used Vim with an external file-browser. :)
If anyone's interested in opening files in an existing gvim window from the terminal, here's the script I use in Linux:
gvim -f --remote-tab-silent "$@" &
If only Lion supported multiple monitor full screen.. :S
defaults write org.vim.MacVim MMNativeFullScreen 0
vim --servername FOO
vim --servername FOO --remote-tab ~/.bashrc
You do have to have an X server available though; the client/server communication occurs via X.
On my mac I end up using MacVim mostly so that my Vim and Terminal apps can be considered separate apps for the purpose of things like spaces, and it just seemed to integrate a little better with the Mac infrastructure.
But in general I haven't found a reason to prefer a GUI version over a terminal version when a sufficiently capable terminal is available.
- The excellent "solarized" colour scheme only works properly with 24-bit color unless you're willing to mess with the terminal palette and break all your other terminal apps. No terminal I know of supports 24-bit color.
- I have a handy keybinding that cycles through open windows and tabs, I find it makes the most sense bound to Ctrl-Tab and Ctrl-Shift-Tab. Neither key can be bound in any terminal I know of.
I haven't had any trouble binding <ctrl>-based combinations. All my window-manager commands are based on <super>, leaving <alt> and <ctrl> open for other things. I assume <ctrl-tab> is conflicting with tab swapping in gnome-terminal or something similar.
alias vimtab="gvim -f --remote-tab-silent"
in your .bashrc, .zshrc or equivalent
$ open -a macvim filename.ext
$ alias mvim="open -a macvim"
with emacs and ido-mode enabled I press Ctrl+X B to open a buffer, Ctrl+X F to open a file, I typically type 2 or 3 characters from the filename and emacs gives me a list of matches (with autocomplete), usually the first suggestion is correct and I press return to open the file.
I barely need to think while I do this, there is no visual clutter on my screen, and I can usually finish the before someone could take their hand from the keyboard to the mouse and move to the filetree
Users of Visual Studio can get something similar using the Visual Assist plugin. Works across files in the project, interesting symbols in the project, or interesting symbols in the current file. Works as well as you'd expect - or, if you don't like Visual Studio, better.
FuzzyFinder is nice, but graphically it's a mess. Like everything else in vim, really.
Getting familiar with GNU screen and within vim, liberal use of :tabnew foo got me to prefer a terminal emulator for working and notes over eclipse / gedit / nautilus. (gt and gT move to different tabs and :tabm N moves the current tab to tab N btw). If from within vim you :mksession bar.vim, vim saves all your open tabs so you can :wqall and open the tabs again from the shell with vim -S bar.vim
Like seemingly everyone, I organize projects into project/doc, project/src, project/data, project/bin etc. For example, I have a start.vim each in project/doc and project/src.
Then I put lines in ~/.screenrc
screen -t myproject_doc vim -S start.vim
screen -t myproject_src vim -S start.vim
screen -t bash bash
The point is it fires up work for me so I just have to open a terminal and type screen and it's instantly ready compared to opening eclipse or visual studio and then navigating to the relevant related notes and documents, or cluttering up the place with a billion (or even 2 or 3) terminal emulators, since screen multiplexes them. I also like to have screen windows open with cmus (music) and a python interpreter (my calculator and preferred random 'what to make for dinner' decision maker).
I also prefer the command-line environment for programming and also most general use because of the kool tools it's full of you are no doubt very acquainted with (ls, locate, grep, less, ps, pipes et al).
(End of mysteriously censored post.)
I have no idea why this might have been censored. Maybe it's the obnoxious use of "w/e" as an abbreviation for "whatever"?
This is why I browse with dead comments enabled. A single particularly poor comment is a rather inaccurate indicator of future comment quality.
Command-T forces you to think: where is this file? And then you type in a handful of characters and retrieve it immediately. To me, that is very vim-like, because it's similar to the editing experience, where you think: what is the most efficient way to do X?
At this point, basically, if an editor doesn't support PeepOpen, I won't use that editor.
What's in your config for it?
In MacVim preferences, I set "Open files from applications" to "in the current window / and set the arglist"
However, it seems like the author learned the basics of vim, but stopped before he learned about powerful navigation keys, visual mode etc.
I think the moral is: if you feel you don't get the hang of vim/nerdtree etc., don't give up - keep going, there is a reason why so many people use it.
Yes. All the tutos I have read recently insist on using hjkl, which is a matter of taste, but do not emphasize what I believe is the most important (for terminal use): cut and paste.
- Easy cut and paste in Vim is done with yy and p, avoid mouse and ctrl-c/v or any other trick that is not "inside" Vim.
- Good trick are to first select a block with <shift-V>.
- Don't forget P, which is pasting above current line or before cursor, often more logical than p.
- This implies to open different files inside the same Vim instance, using :Explore or :edit
- If you have to copy some outside text inside Vim, by all means, use the paste mode (:set paste), if you don't you'll mess up your text.
"_ is the blackhole register, with this the replaced text disappears and you can continue "putting" the new text at will.
The way people work differs from person to person, the idea that someone should always just keep on trying, even if something doesn't feel right, is in my opinion useless. The real moral here is that people should accept that everybody is different and that it’s ‘ok’ for them to be different and how great it is that open-source software such as vim enables them to do so. Something that’s unfortunately always a bit harder for passionate users. (No insult intended!)
I definitely know that _I_ prefer to browse a project with a GUI that works like in the rest of my platform of choice, but I also know I’m very different from the average vim user :)
I can use vim. I know it pretty well. But the inescapable fact is that, for me, it's clunky and requires more thinking than just using a mouse and pointing at something, then typing what I want to type. I use it because I haven't found something better (and I'm sure it exists, I just haven't seen it).
As it happens, I do.
It's a text editor, not a religion.
It's an awesome text editor. Who said anything about religion?
Even after learning a lot of the commands and the different modes, it never grew on me.
I think it is a shame as I touch-type and try to minimize the use of the mouse via shortcuts.
For me, vim is surprisingly similar to drinking scotch: I first tried it at age 19, and wasn't pleased with my experience at first. But a wise mentor informed me it took a little getting used to, showed me how to do it right, and after a month or two I loved it.
There are some holes in the vi commands that I use; some of them can be filled in (I'm working on some of the ones I'm missing), some of them will probably have to wait for official work, but either way I'll probably keep using it for a few days and see how things feel at the end.
I tried plugins like NERDTree, which are awesome in one way because they work everywhere vim works (like in the terminal). However, I didn't really like their feel in combination with GVim and tabs.
It's all about what's going to be fastest and take the least amount of mental context switching. I didn't choose vim because it's so hard to move to the mouse occasionally, I chose it because some things are much faster/easier than in TextMate, and for some things the mouse is still faster.
Sure, from a purist point of view it's terrible, but I think vim mastery has diminishing returns at some point (granted, it's a pretty far point up the learning curve).
I do this to get nice access to multiple files:
set hidden " allows files to be opened in background
nmap <C-j> :bp<CR> " edit prev file with ctrl+j
nmap <C-l> :bn<CR> " edit next file with ctrl+l
I found FuzzyFinder slow and it interrupted my workflow.
There seems to be a big divide in usage between gui vim'ers who are probably doing one window/ide thing vs terminal vim'ers who probably have multiple terms/vim's open and use unix/cmd line as their die.
Note I make value judgment as to which is better (I'm sure people vary and so should their tools). My point is you should figure out which one you are and filter vim suggestions appropriately
I work on a lot of OSS projects and our company does consultancy. This means I browse other’s projects on a daily basis (i.e. I don’t know the filenames yet). That, combined with the fact that I have a deep love for GUI design and platform consistency, has made me come to the conclusion that something like NERDTree wasn't working for me. I tried to keep on going for a few more weeks, but in the end I decided that writing a file browser would cost me less time than I lost during these few weeks.
I’m glad I wrote it, because now I’m perfectly happy with my MacVim setup, which I wasn't before. I’m also very glad I did not decide to revert to using TextMate or any of the other new closed source editors.
To conclude, it’s a bit of a feeling-thing. I’d invite you to try it out for a while to see if it works for or against your flow. No hard feelings either way :)
PS: It might not be apparent from the article, but the browser provides a few more functions that os x users might be used to in other apps. See the last screenshot: https://github.com/alloy/macvim/wiki/Screenshots.
Browsing codebases that I am not familiar with is the exact use case for me. For navigating my own project, I do fine with MacVim + Terminal + "mvim in new tab in existing window conf" . But for exploring an unfamiliar codebase, it's too cumbersome.
alias mvim="open -a MacVim.app"
In MacVim Preferences set "Open files from applications" to:
"in the current window"
"with a tab for each file"
I normally use vim on the command line, but a lot of my coworkers use gVim on Windows. Whenever I try to help one of them out, I can't stand the fact that ctrl-v is remapped to paste by default. I recently found out how to make gVim sane again. In _vimrc, comment-out the following lines:
EDIT: I think it also works on Linux... Sitting on my Windows box, at the moment, so I can't test it.