Not to rain on anybody's parade here, but for first-time vim users I recommend not using any plugins and only selectively adding them one at a time after the basics (buffers, navigation, some ex mode, etc) are at least somewhat familiar.
Getting started with plugins enabled makes it hard to understand where vim stops and plugins begin and make switching to a different (someone else's) vim setup confusing at best.
It also tends to feed the 'make it work like the last editor I used' syndrome, which is completely counter-productive.
Otherwise, nice work and good job open-sourcing it!
Completely respect where you're coming from, but totally disagree. I made a few abortive switches to Vim that didn't last a week because my productivity was too hampered and the environment too extreme & foreign.
To a newcomer like me, Vim's built-in help was less than worthless, since you pretty much need to know the Vim term for what you're looking up to find it. Googling around wasn't much more effective (there's a lot of garbage in the Wikia for Vim that comes up at the top of many searches).
In the end, I needed to read these two "gentle" introductions to Vim to even understand what it was all about:
…and then I needed a mostly-well-documented distro like Janus (https://github.com/carlhuda/janus) to ensure that my productivity wouldn't take a huge hit those first few weeks.
Some folks can probably go all-in cold turkey, but I needed the training wheels.
The problem wasn't the "extreme & foreign environment", the problem was that you thought wrongly that you could learn Vim as if it were a regular editor.
Learning Vim is a side project: something you do casually, slowly, until and if you are able to do the actual switch.
Those braindead distributions are just smoke mirrors for lazy and pressed people: they provide training wheels but they actively prevent you from actually learning core Vim. They make people $distribution_name users instead of Vim users.
> Learning Vim is a side project: something you do casually, slowly, until and if you are able to do the actual switch.
No one appointed you the director of how one learns Vim.
This is one of the most obnoxious parts of Vim threads: that guy that responds to people talking about how they learned Vim (past tense, as in already happened) and tells them that they learned it "wrong".
I second this. I've really underestimated how big an impact first impressions can leave, especially when dealing with completely unfamiliar tools.
My first intro to Vim could be called "haphazard" at best because I was pressed at the time, and so that thoroughly soured the relationship. It was only after I took a few steps back and went at it with a let's try this again attitude very slowly did I finally get through it without exhausting myself. I wish I took the slow route the first time.
Best way to learn Vim is to learn it for the sake of learning it. Not because "it's in the way".
In the long run, the distros are also a dead end. Neither Square, nor "Carlhuda" share the same commitment as Brian Moolenaar. If you find them useful then take advantage, knowing that they are only a fixed point within the ecosystem.
The Gentoo Linux vim tutorial is how I learned. It took me about an hour to become as productive in vim as I was in my previous editors (nano, GEdit, some random Windows editor, etc.) Everything past that was an improvement over any editor I have seen before.
I think it is a lot harder for people used to IDE's, but if you treat it as "get to the minimum productivity level as fast as possible, then slowly add more", you will probably enjoy it.
> I made a few abortive switches to Vim that didn't last a week because my productivity was too hampered and the environment too extreme & foreign.
That was my experience as well. I was pretty comfortable using vim in emergencies but the few times I tried to make it my full-time IDE failed very quickly. Once I stole Gary Bernhardt's dotfiles[1] I was able to stick with it because I didn't have to start from scratch with keymaps, plugins, etc.
* A core engine that understands the code you write.
* The ability to run this engine in the background.
* A unified API that would make possible for plugin authors to interact seamlessly with that engine but also between each other.
* Certainly a thousand of minor details.
You can add as many fancy plugins as you want, you'll never get an IDE.
You'll get something that looks more or less like an IDE and works more or less like an IDE, but not an IDE because an IDE is not a text editor with a file explorer on the left, a class explorer on the right and a list of compile errors underneath. It is much more than that and Vim doesn't have and can't have that "much more".
Unless you count external compilers/debuggers/profiler/linters as that "much more" but that's still not an IDE. A DE, maybe, but certainly not "I"ntegrated. Well, not even an "E"nvironment, actually, given Vim's design principles.
I always forget when i've started these discussions sorry for the late reply.
That's a pretty narrow definition of an IDE, especially since the history of IDE's goes back far before a time in which any IDE could be said to have a core engine that understands the code you write. In fact that "requirement" is almost entirely driven by the rise of Java and the ridiculous amount of code it forces you to write. Prior to Java IDE's I can't think of a single IDE that could be said to have such an engine, including Visual Studio who's features in that regard were driven by competing features in the Java world.
The 2nd requirement is obviated by the lack of the first; the 3rd and arguably the 4th are already present in vim. An IDE, at its core, is exactly what you claim it is not: a text editor that provides navigation features (possibly but not requiring a class navigator—you seem quite focused on object oriented features) and an ability to run the code under discussion. Emacs very definitely is an IDE under the limited definition you provide, including an engine for understanding the code you write.
I'm also not sure about why you think external compilers/debuggers/profilers/linters are disqualified from being the core engine you're fixated on—you realize that every IDE out there does exactly that, right?
> I made a few abortive switches to Vim that didn't last a week because my productivity was too hampered and the environment too extreme & foreign.
I started vim by using cream[1], which behaves like a normal editor with menus to configure everything. Once you get used to the different concepts, you can start editing the `.creamrc` file. After a few years, I was comfortable enough to drop cream completely and use hand written vimrc file for the configuration that I liked.
The best I can recommend is Learning the vi Editor by O'Reilly. This book will really teach you to understand the command languages of ex and vi (and how they interact). Once you've mastered that, vim will make a lot more sense as it's just a gigantic pile of extra stuff built around that core functionality.
For me it was using pentadactyl for a while beforehand that made switching easier. Obviously there are different concepts and some different default keybindings but pentadactyl is much easier to incrementally get used to imo.
Another thing that people often forget when they use plugins on their development machine is that if they happen to ssh into server (or work on another user's machine), it is unlikely that it will contain the same plugins. It is better to become effective at using the bare vi/vim commands first and only use plugins as a time-saver.
This is true for using plugins in any editor/IDE. Where do you draw the line. Should I use my own `.vimrc` file and set textwidth, formatting-options, indenting, etc. according to my preference, or don't tweak anything at all because those tweaks will not be available at another user's machine/ssh server? It is relatively easy to have your configuration files on a USB/dropbox and copy them on a new machine if needed.
I absolutely agree. Trying to use 'oh-my-zsh bundle' analogues for Vim is absolutely the wrong approach (for that matter, I think oh-my-zsh itself is the wrong approach). There is enough to learn already, blurring the line between what Vim does and what plugins do does not help the situation at all.
This said, I think these sort of dumps are great for experienced vim users who can pick through them and find individual fragments that they want to adopt.
That is a sensible suggestion, I would go further and suggest that new users impulsively reject answers to questions "How do I do X in vim" that are "use plugin y" and find a native way of doing it, because plugins will increase the difficulty in working in new environments.
Using vi instead of vim for a while is also beneficial. It keeps one from learning bad behavior like typing 'i' and then hitting the arrow and necessitates learning about marks before being spoiled by the visual modes
I definitely agree. Vim was much more confusing for me while still a beginner, partly because I started with first the spf-13 distro and then haskim, a haskell-focused distro. I didn't really start grasping how things worked until building up my own distro. The funny thing is that most distros I've seen still include many of the same plugins, making the end product only unique in the details. Those details however, are blockers once you're set in your ways...
as an anecdote, i've been using Vim for almost 10 years and i've never used plugins. the extent of my customization is setting the font/color scheme in the vimrc
Long time VIM user here and I completely agree, not only for beginners, also for pros.
Basically it follows the KISS, and in some sense UNIX, principles.
I have never used the vim distros but I have gotten to a point where I just rm -rf'd my whole .vim dir and started over with only the plugins I required at the time. Then added more as I needed them.
Of course, I have always managed well without the file browsers many use.
Normally I would agree, foundation first then mature into plugins and add-ons however after looking into Maximum Awesome I believe it will help new users overcome the learning curve frustration that vim is known for; very nice. kind of like a twitter bootstrap for vim
I'd say that syntax/completion scripts are an exception as they are pretty much mandatory if you're writing code in a language that hasn't made it's way into the official release (and to be frank, there are a lot of gaps).
Great to see some love for tmux. Terminal vim + tmux is a lot more powerful than Gvim or MacVim.
That said, I started using vim with Janus and while it convinced me that vim could be a great modern editor, it left me too confused when I tried to make my own customizations. I ended up ditching it and hand-picking my own plugins. I suspect a completely new vim user would likely experience the same process with Maximum Awesome. Still, that doesn't mean these curated sets of plugins are a bad idea--if anything they can serve as a proof of concept for people who aren't yet convinced on the value of the editor.
A vim plugin pack could work very well—I think the problem is with many of the plugins, which were built to scratch the author's itch and inadvertently dig their tendrils into half of vim's functionality. That's sort of tolerable when installing them one at a time (and figuring out how to loosen their grip one at a time), but every time I've installed a plugin pack I've suddenly had a vastly different vim that was both buggy and much slower.
gitgutter, ctrlp, and pretty much anything from tpope are all great in this regard: they do one localized thing and it Just Works. (Downside is when that "one thing" is a shortcut or function, and with no other cues I forget I even have the plugin installed.) On the other hand I've had pretty terrible experiences with SuperTab, which required a lot of fiddling and still breaks my Tab key sometimes, and ctags is such a pain that I've never gotten around to making it actually work. But those are useful enough that they end up in most plugin bundles, so you get a Cartesian product of the interference and brokenness of all of them.
You realize you're the only one "going" when you pick just one single phrase out of his whole post and make this kind of remark on it, right? You're not exactly contributing to the discussion...
Basically, terminal multiplexing solves a different problem than window management solves. Terminal multiplexing gets you detach/reattach (letting you switch computers trivially), per terminal splits (which I frequently use in addition to WM tiling, similar to how I use Vim windows in addition to both of those), and better scrolling/highlighting.
Can you elaborate on this? I also use XMonad in connections with a simple xterm (although I used screen some years ago, but then I did not know about XMonad) but I do not get the idea of detaching/reattaching. Is the idea to save the state of the session?
If you are running tmux locally it would allow you to do things like kill X, log back in, open a new xterm, then pick up where you left off. The session isn't paused or suspended, it continues running the entire time even though the gui terminal emulator died.
If you are running tmux remotely, then it lets you start working at home on your laptop (over ssh), close your laptop, drive across town, turn your laptop back on, ssh back in, and pick up where you left off.
The way I use this at work is I have many long-running tmux sessions running on my desktop (one for each 'project', and one for a few interactive db sessions and the like). I then work over ssh with a fullscreened Putty instance. When I want to switch projects I can just hit C-b s then select the session I want to switch to.
At home I use a laptop with linux (and the Awesome WM (similar to xmonad, though less hardcore I suppose)) but most of my 'work sessions' are on various other machines. I ssh into them and connect to the correct session with tmux. Since Awesome lets me arrange windows with tags I do that a lot for work sessions (like tagging a few terminals and a browser window that has docs opened in it) but I consider those to be more ephemeral. I close them out when I start running low on resources (memory, cpu, battery, etc) but the tmux sessions live on (local or remotely).
(I use to use straight up xterm as well, but switched to urxvt because my new laptop has a high DPI screen that makes urxvt's nicer font rendering support sort of necessary.)
I'm restarting X all the time, so I'd see tmux with my test/log window a huge gain. For vim, I prefer gvim for better and faster rendering over any terminal.
How is urxvt's font rendering support better than xterm's?
Having
XTerm*faceName: Inconsolata
XTerm*faceSize: 14
in .Xresources gives me exactly the same result as with urxvt or gnome-terminal.
(P.S. Awesome is not at all less "hardcore", just works differently and is kind of a required taste.)
Agreed. I do still use MacVim quite a bit as it integrates well with environments that allow selection of an OS X app as editor. That said, a tmux + vim setup is a great combination, especially if mouse (well, trackpad) scrolling support is enabled in both.
I've picked up a few new tricks from their setup as well -- e.g. see the "Fix Cursor in TMUX" comment in vimrc.
I disagree on that front. Managing git repos is easier for me to do the way I always do it than with a slightly auto-magic system specific to those sort of git repos. Pathogen does a little, but does it flawlessly. Vundle does more, but the more it does is far less elegant.
I second this. I was hesitant at first but after trying it for a couple of minutes after getting the tricky config right (thanks to some helpful bloggers) I was very happy. And shuogo was very responsive to new issues, providing fixes within hours sometimes.
CommandT is nice for really large repos. At my last job, I worked on a very large rails codebase and CtrlP frequently took 5+ seconds to index, while CommandT was under one second.
I also worked with the author of CommandT at that job, which was nice.
Yes, you are missing something: it's a joke. People sometimes overstate things to achieve a comical effect. People use comical effects for a variety of purposes: to get other people to like them, to make themselves (and the things they make) look more approachable, to covertly criticise their own weaknesses and so on. You might not find it very funny but you know, it's still a joke. Obviously.
As another commenter already pointed out, a common pattern is for people to try such a configuration, and end up starting again from scratch because, frankly, it doesn't work for them.
Emphasis on "for them".
I'm not saying you shouldn't share your setup. I wouldn't have learned vim (or screen back in the day, or pine, or many others) if I didn't crib from the dotfiles of those before me.
But at some point, your setup becomes so customized to you that you're the only one it works for. And that's why vim and emacs, ancient editors, still exist -- they're stable and can be modernized and tailored to the user over time.
I would love to know why they have chosen Pathogen instead of Vundle to manage plugins. As hard as I try, I can't see any reasons why Pathogen is greater than Vundle. Can someone enlighten me?
Pathogen and Vundle have different purposes: one could be called a "runtimepath manager, it injects the plugins found in ~/.vim/bundle into Vim's runtimepath like if they were installed the standard way, while the other is really a "plugin manager", allowing you to update, install, delete, deactivate plugins.
Because they have different purposes, they must be compared according to your needs.
I don't need a "plugin manager" but I like my plugins to be organized cleanly so I use Pathogen.
If you need something to help you "manage" your plugins, Vundle is a sensible choice but you should compare with VAM or neobundle.
In short, comparing Pathogen and Vundle makes no sense: compare what's comparable.
Chalk it up to different preferences. I prefer Vundle too, never could get Pathogen to work, but Vundle just does for me. But others were using Pathogen before Vundle appeared and have no reason to switch.
Everyone used Pathogen before Vundle, as Pathogen is older.
However after an extensive use of Vundle, it's the fastest way to deploy your environment from scratch - or to add, modify or delete a plugin. I really don't troll here - but honestly, managing plugins with Vundle is such a joy that I don't see why a company like Square releases a Vim project using Pathogen. And I'd looveeeee to know the reasons - is it indeed because of personal preferences or is there something I'm missing?
It's literally copy and paste. I understand preferences and taste, but you make it sound like you need a degree in particle physics to make the thing work...
I know, and back when I tried it, which was probably years ago, the problem was .vimrc line execute pathogen#infect() always errored out. Couldn't figure out why at the time, then found Vundle, it worked perfectly, been using it since.
This is cool but it seems silly to have the default install method to be using "rake", I love vim but keep Ruby off most of my systems, what happened to good ol' fashion shell scripts.
In practice I've found bundler to be just another layer that can have the wrong version: http://xkcd.com/927. But I have no interest in bringing up old painful episodes, I'm done with the ruby eco-system. So I'll just restrict my response to the previous paragraph.
This configuration also includes the Command-T plugin, which has a Ruby dependency. For those looking for a Command-T alternative without Ruby, CtrlP is a great choice.
I seem to be getting an error: Warning: Permanently added 'github.com,204.232.175.90' (RSA) to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Checking connectivity... done
Submodule path 'vim/bundle/jshint': checked out 'da21f0eb658d9af6696ee34a00c13d1717d85095'
Cloning into 'vim/bundle/kwbd'...
Permission denied (publickey).
fatal: Could not read from remote repository.
I started using vim about a year ago, by using the janus vim distribution, which was great to get me started. However, I since started again from scratch to know what's there and why. So I won't be using this at all besides for the implicit recommendations of existing plugins (like the_silver_searcher, which is really crazy fast).
Overall, this seems like a great way to get started with vim because it doesn't have too many plugins but it still has the minimum features expected from someone who used Sublime or Textmate.
edit: looking at their .vimrc, there's a lot of stuff that I'll use right away. Definitely useful, just not as a straight download/install for me.
Surprised that people are actually trying this. IMO there are far better configurations out there if you want to try a pre-tailored one. Google for them, i'll add my personal favorite here since people are actually up-voting and installing this less than impressive config.
If you use ruby/rails try yadr https://github.com/skwp/dotfiles.
If you don't use ruby, it (imo) still has one of the best key maps/configs for beginners just delete the ruby plugins.
Make it yours:
:help every plugin and every setting if you don't know what it does. Change any key mappings you don't like. It will take about 40 hours to familiarize yourself with everything, that is if you go plugin hunting yourself. I'm not a believer that starting from scratch is the way to go.
Add YouCompleteMe, vim-detailed, vim-notes, vim-slime, vim-numbertoggle, vim-abolish, vim-startify, vim-textobj-rubyblock, switch.vim, ultisnips, vim-airline, unite (check out unite plugins), vim-expand-region, vim-jsbeatify, extradite, vim-diffchanges, vim-speeddating, goldenview or golden-ratio.
This config probably won't run well on machines that are older than 2012, in total there are about 90 plugins. Remove any plugins you don't need. Look up how to profile your plugins, if one of them is causing things to be slow remove it. Don't install anything without reading the help file immediately afterwards.
Learning enough vim to match your current productivity is not as difficult as everyone makes it out to be. I was instantly more productive with this setup switching from RubyMine and I still have barely scratched the surface of those help files. Disclaimer: I had picked up the most basic motion / visual selection keys previously working over SSH. And I was familiar with window/buffer management from using tmux daily.
I'm sure that most people, like I at first did, are wondering how useful a game could really be. Answer: Very, very useful. I think Vim Adventures was a way better headstart for me to learn the Vim style of thinking than pretty much anything else could be.
Start by deleting that crap, then run $ vimtutor until you are comfortable, read :help carefully, try your hands on simple tasks first then augment the complexity… after a couple of months you'll be as productive as before or more and, maybe, ready to do the actual switch.
Try vimtutor before you begin with these plugins. You'll learn a lot of basic motions and also get the feel for how to speak vim, combine motions with count arguments, etc.
Looks pretty much like my setup except Command-T. Command-T is awesome on Mac but it's a pain to make work on Linux and not sure about Windows. Moved on to ctrlp plugin.
Unfortunate that they don't mention licensing at all. (EDIT: Whoops, I'm completely wrong. Sorry. Move along, nothing to see here.) Since they use Git submodules, some licensing is inherited from packages like Command-T and vim-fugitive... but they wrote code themselves as well, so there's also that.
https://github.com/carlhuda/janus is a slightly more plugintastic distribution. There's a lot of plugins included and they've all been configured to work well with each other.
Um, what? There's a suite of 35 plugins used in Maximum Awesome. It's using Tim Pope's pathogen plugin[1], so they're all listed in .gitmodules instead of directly in the .vimrc or in an included bundle file as with Vundle[2].
It's \\\ and it comes from the commentary plugin. It was the default mapping when it was released but it was changed a few months ago. \\\ is still available, though.
Yes, lots of people use <leader>something mappings because they offer a lot more flexibility than <C-something> and friends. What you use as mapleader is up to you, "," is simply the value suggested in the doc.
I keep `q` to record macros, but complement that with :noremap <Space> @q That way I can press `qq` to start recording, `q` to end, then just wack the spacebar to execute. I use it constantly.
comma is really useful as a leader and it's not so far away on the keyboard. No one I have heard of uses ctrl for leader(it would ruin a lot of ctrl-whatever commands) and by default the leader is a backslash.
Nothing here is fascinating to me. Many devs confuse Vim for an IDE. Not sure why...
Don't get me wrong though, first thing in every Debian install I do is to replace vim-tiny and nano with vim as the default editor.
I like to think I appreciate vim for what it is, not for what it can be forced into.
cmd+t lookup is not a good vim thing... it's slow requires me to move my hand to the right to navigate using arrow keys... also it's slow. changing files takes significantly longer... it's bad enough how slow the iterm.app is on osx and don't even get me started on the slowness of the terminal.app -- picky vim user
update: i like the empty line space indicators little boxes look cool
You can hold down CTRL and use j/k to move up/down (so you don't have to use the arrow keys). It can be slow on very large directories.
I switched to CtrlP last week because I switched OSes at work and didn't want to recompile vim and Cmd+t. In the past CtrlP was significantly slower, but I found a few new features that actually makes it faster than Cmd+t for me; it automatically navigates up looking for a .git or .svn to search from instead of cwd, and you can set up caching (persistent between sessions) and max num of files to scan--I believe you can set a timeout, too. I also setup a filter so my build folder and docs won't show up.
Since finding Cmd+t, it's been the fastest way to navigate to files in a project (especially when they're not in the same directory).
The whole point of Command-T, FuzzyFinder, CtrlP and friends is to provide "fuzzy" completion. They don't display a list of files for you to navigate with the arrows they display a list of candidates that you refine by typing more characters.
spf13-vim is pure vim script. No ruby required.
spf13-vim is cross platform and works well on windows.
spf13-vim uses a bundle system to make easy maintenance. Git submodules lock you into a specific hash of each plugin and maintenance in keeping these up to date only increases your commit count with empty commits.
spf13-vim is built to be a base and completely customizable. This is built to be your vim config.
Lastly spf13-vim has dozens of contributors supporting a variety of plugins and languages. This seems focused on squares stack, ruby & coffeescript.
Disclaimer... I'm spf13, so a bit partial, but if you look at spf13-vim from 2 or 3 years ago it looked a lot like this... and we've learned a lot from making some mistakes present here.
Not really, since it's developed by them and for them (a mac house). He seems pretty welcoming of your additions to make this Linux/Windows if you desire... but why on earth one would expect that THEY would have taken the time to make this multi-platform when they don't use it that way is honestly beyond me (i.e. silly).
Yes but VIM runs on everything, why make it Mac OS X specific when it's simplistic to make it "just use these vim files and it'll work on every computer"
Getting started with plugins enabled makes it hard to understand where vim stops and plugins begin and make switching to a different (someone else's) vim setup confusing at best.
It also tends to feed the 'make it work like the last editor I used' syndrome, which is completely counter-productive.
Otherwise, nice work and good job open-sourcing it!