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!
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:
http://stevelosh.com/blog/2010/09/coming-home-to-vim/
http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...
…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.
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.
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.
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.
What exactly was it you were doing faster and better in your previous editor (which was?)?
> the environment [was] too extreme & foreign
What about it was weird?
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.
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.
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.
Oh God, here we go...
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.
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.
I've picked up a few new tricks from their setup as well -- e.g. see the "Fix Cursor in TMUX" comment in vimrc.
It's not like tmux didn't get any love these days.
Not to mention it's not maximum awesome: CtrlP > Command-T and Vundle > Pathogen.
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.
http://www.codeography.com/2013/06/17/replacing-all-the-thin... https://github.com/Shougo/unite.vim
I also worked with the author of CommandT at that job, which was nice.
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.
This writeup (not mine) I completely agree with: http://mislav.uniqpath.com/2011/12/vim-revisited/
Starting from blank and building my own dotfiles is what did the trick for me. Using a big ass template actually made it more difficult.
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.
https://github.com/tpope/vim-pathogen#installation
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...
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.
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.
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.
Remove vim-snipmate, neocomplicache, vim-snippets, vim-colors-solarized. Remove nerdtree nerdtree, vim-nerdtree-tabs, use :e/CtrlP instead.
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.
To everyone I highly recommend YouCompleteMe, vim-detailed, vim-notes, and https://github.com/rking/vim-detailed.
I know a few basic vim commands (switch modes, edit, write, quit) but have never used it to work on a complete project in a directory.
In the mean time, keep using ST on your projects.
https://github.com/christoomey/vim-tmux-navigator
"Seamless navigation between tmux panes and vim splits"
So great. Off to check another random side-project off the list...
[1] https://github.com/tpope/vim-pathogen [2] https://github.com/gmarik/vundle
Also does anyone see where they are setting the /// to comment? Commentary uses gcc and I don't see it in their vimrc.
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.
P.S. I mapped `Q` to recording Macros, since the default use of `Q` is completely useless to me.
sudo xcode-select -switch /Applications/Xcode5-DP6.app
To get the command=T to compile
and I get:
$ git clone git@github.com:square/maximum-awesome.git && cd maximum-awesome && rake
Cloning into 'maximum-awesome'...
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
update: i like the empty line space indicators little boxes look cool
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).
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.
I remember having tried it once and abandoning because it lacked this feature (or didn't work out of the box).
