I've always been a little puzzled by people who use a file-drawer or file-list or similar addon with Vim, and I now I think I know why: I'm guessing most of these people have Vim open as their One Tool, much like another programmer might have Xcode or Visual Studio open as their One Tool, and they want to get everything done in it.
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 "$@" &
(I believe MacVim comes with a similar 'mvim' script you can use on OS X) If you don't want files to open in tabs, change "remote-tab-silent" to "remote-silent". If you call the script and there's no existing gvim window, a new one will be created.
I do literally the exact same, I rock MacVim in fullscreen surrounded by Terminal sessions on the left and right, left for building/opening files, the right for tailing the syslog.
If only Lion supported multiple monitor full screen.. :S
The remote features require a version of Vim with GUI features compiled in, but you don't have to run vim in GUI mode to use them. The only difference is that when started in console mode, Vim won't register itself as a server unless it's explicitly told to use a particular server name:
vim --servername FOO
If you start vim in another tab with the same servername, you can open files in the first Vim, no problem:
Under Linux I always run vim in a terminal. Part of this is habit because I (in the past) often edit files on remote computers and I like the consistency.
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 reasons I run gvim rather than terminal vim are basically all because sufficiently capable terminals do not exist:
- 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've been using urxvt for a few years now. It supports a full color range and I adopted Solarized for a while, but went back to Tango.
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.
I have found issue with this recently. When I have multiple tabs open, and then attempt to open multiple files after that, it opens them all in a split view :/
Thanks that will help a lot(although I mostly use eclipse these days) but for smaller tasks having to reopen gvim with more files or opening new files can get annoying(also the lack of project/file groups checking).
I have a hard time watching people traditionally navigate filetrees and tabs
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
In an ideal world, ido-mode would be the standard for any kind of selecting from a list. Drives me nuts that there are still people out there writing programs that only search by prefix, or that make you actually click the mouse!
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.
Oddly enough, despite the title, the author of the post switched precisely to this, because the new config he found included the Cmd-T plugin, which mimics TextMate's Cmd-T functionality, which is basically what you're talking about here.
I was on the borderline between vim and emacs for a long time. I finally ended up with emacs because it handles editing multiple files and switching between them way better than vim in its default configuration. It also has a saner scripting language. Plus, I get a bunch of goodies, such as org-mode, RPN calculator and an integrated shell. Though I still start vim when I need to edit one or two files on a remote computer via ssh connection.
One of the biggest shortcomings of vim is the lack of a good ido-mode style file-opener. People seem to rave about command-t, although getting it set up on Windows proved too annoying for me.
FuzzyFinder is nice, but graphically it's a mess. Like everything else in vim, really.
This is the biggest meta-shortcoming of vim: the fact that it doesn't come with a built-in programming language. This forces extension authors to bring their own, with the expected consequences.
I recently wrote something very similar to Emacs' ^xf for VIM. Sadly I haven't the time to work on it as much as I would like. For those who are interested: you can grab it at https://github.com/Bogdanp/quicksilver.vim .
Reposting this for horseshoes; it seems to have been mysteriously censored.
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
chdir /home/horseshoes/workin/myproject/doc
screen -t myproject_doc vim -S start.vim
chdir /home/horseshoes/workin/myproject/src
screen -t myproject_src vim -S start.vim
screen -t bash bash
When I start screen it automatically opens one window containing a vim sesh with all my most-looked-at documentation tabs (so I can refer to wth I was thinking and organize my mental pushdown stack a little), one window containing a sesh for the source files I currently work on, and a third window holds a shell so I can look for and alter other files or start sqlite3 or make or w/e.
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"?
Certainly some moderation is appropriate for that comment, but I think a permanent invisiban is a bit of an overreaction to that. Does this kind of thing happen frequently?
A lot of people miss the issue of browsing through projects that you aren’t familiar with. Auto-completing/fuzzy matching takes more time than actual browsing in such a case, because you’re probably guessing half of the time. Maybe it’s just me, but I find that to be annoying within a minute.
VIM defender rushing in. I wrote a post which translates 100 Textmate features into VIM, and vice-versa. In particular, I included a section on getting used to the NERDTree.
I agree completely about Command-T. I don't use any type of file drawer at all, I tried NerdTree and found it really annoying. The way I see it, you either know where something is already, in which case Command-T does the job, or you don't, in which case you may as well use a console, or just use :edit . in vim to open up the file & folder browser to start browsing around.
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?
Surprised PeepOpen hasn't been mentioned yet. I use it exclusively with MacVim on OSX. It is a bit unconventional but works amazingly well: http://peepcode.com/products/peepopen
I've got this, and I find it's better than Command-T, better than Jamis Buck's now-antiquated FuzzyFinder, and even better than Textmate's own command-t functionality!
At this point, basically, if an editor doesn't support PeepOpen, I won't use that editor.
I actually used PeepOpen a lot when I was still on TextMate, but I totally forgot about it after using Command-T for a while. I'll check it out again if I run into any issues. :)
I have struggled for a while to get PeepOpen and MacVim working together. I can run :PeepOpen, and it will switch to the running peepopen application, but it doesn't load up with the project files. I've tried all sorts of .vimrc config settings that the internet has to offer, but none worked.
I too wanted to click around the first month (+/-) after switching to vim, I think we all did.
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.
Also worth remembering is that every command that deletes really cuts. Which is to say, deletion commands like x and dd store the deleted content in the register that will be used when you hit p or P. This is important to know both because it can be very useful sometimes and because it can get in your way other times (e.g., if you're trying to repeat an action and keep replacing a line with another line, you'll have to paste before you delete so you don't override your register).
The reason that people use (mac)vim is not necessarily the ‘powerful navigation keys’ etc. For me it’s the ability to deal with large files and the crazy indentation rules people use and I know it’s the same for quite some other users.
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 :)
Agreed - this is pretty much the only reason MacVim lives on my machines. It handles huge files way better than anything else I've tried.
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).
That's exactly why I tried again. The drawer is just a way not to go completely mad when I'm stuck trying to open files "the fast way" and I think these tools make it easier for people to get the hang of it. :)
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.
I've been playing around with vico for a couple of days (http://vicoapp.com/) and it seems pretty nifty in terms of solving some of these from-textmate-to-vim "problems". It uses TextMate bundles and supports them reasonably well as far as I can see. It also has Cmd-T and is very much a native app rather than a wrapper around a terminal app, which is more what MacVim tends to look like (it's what I've been using for the couple of years since I switched to Mac).
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'm working on a Gtk2 application that basically solves the same problem. It adds a sidebar with things like a file browser to a GVim editor. For getting a feel for a foreign codebase I find it much easier to use something like this than to switch between navigation/file view all the time.
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.
I created a fork of janus that removes NERDTree from the distribution just for using it with alloy's fork. Also some other nice textmate behavior like quote/brace completion is included. So to get started immediately you can use it too, it is on github: https://github.com/JFrolich/janus
I still click around in MacVim sometimes (mostly for navigating deep NERDtree hierarchies and for selecting text within a line).
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).
The author mentions trying to get around this with the nerdtree plugin. I stay away from heavy plugins like this because I think they compete with the minimalism that is so nice to the feel of vi. But I can see why you'd be attracted to it given the difficulty of dealing with multiple files.
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
FuzzyFinder is the easiest file and buffer navigation plugin I've found. You should try it. Fuzzy matching is better than having to keep track of what files you have open and in what order.
The times I open new file vs times :e line is already in my vim/bash history is tiny. And that tiny amount is handled fine by vim's filename completion.
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
There is nothing wrong with being more productive with a tool like TextMate instead of vim, emacs or whatever IDE or editor. You should simply use a tool that works you.
I don't get it. When I am working on a project I just go to the root project directory and open up vim. NERDTree automatically loads the file structure of the project directory which is my current focus. Why should I need a file-drawer with the unnecessary folders showing?
My response wasn't meant as harsh, it just lacked a smiley ;)
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.
I think I will give this a try. Thank you for writing this and taking the time to release it.
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" [1]. But for exploring an unfamiliar codebase, it's too cumbersome.
---[1]---
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"
Then, in Terminal you can do, "mvim file.ext" to open file.ext in a new tab in the existing MacVim window (or new if no window).
I find myself never straying very far from VIM. It keeps drawing me back. The registers, motion commands and fingers never having to leave the keyboard just work so well for me. Multiple tabs in iTerm keep me well organized and speedy.
I'd say most unfavourable opinions are tied to a lack of knowledge but having powerful features ultimately doesn't negate that it's uncomfortable for some.
gVim is hard; I just want to type ctrl-v to enter blockwise Visual mode.
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:
yeah whole post is kind annoying, he wants to do it, but he will not, maybe he will, no he will not, like a girl.
I didn't find vim that hard at all, just learn it and use it, that is all.
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:
(I believe MacVim comes with a similar 'mvim' script you can use on OS X) If you don't want files to open in tabs, change "remote-tab-silent" to "remote-silent". If you call the script and there's no existing gvim window, a new one will be created.