Hacker News new | comments | show | ask | jobs | submit login
Square open-sources its Vim repo, Maximum Awesome (squareup.com)
245 points by JackDanger 1543 days ago | hide | past | web | 141 comments | favorite

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".

>Learning Vim is a side project: something you do casually, slowly, until and if you are able to do the actual switch.

For me, vim didn't take until I used it start to finish on a smaller, week-long project and immersed myself in it. Everyone learns differently.

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.

"vimtutor" is pretty gentle. Alternatively, http://vim-adventures.com/ is just fun.

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.

[1] https://github.com/garybernhardt/dotfiles

Vim can't be an IDE (it lacks the most important aspects of an IDE), no wonder your attempts failed.

what exactly, in your opinion, are the most important parts of an IDE that vim lacks?

* 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.

[1]: http://cream.sourceforge.net/

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.

> I made a few abortive switches to Vim that didn't last a week because my productivity was too hampered

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?

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.

Agreed, also goes for Emacs. Not a fan of starter kits, they tend to confuse experienced users and newbies alike.

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.

Terminal vim + tmux is a lot more powerful than Gvim or MacVim.

Oh God, here we go...

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...

The only thing I really like about MacVim as opposed to Terminal vim + tmux is how fast the cursor moves can move around.

This. I still do not understand why the OSX terminal is so damned slow.

Me either. It's really the only thing stopping me from deleting MacVim.

Any reason why you can't use iTerm 2. Honestly I can't see any reason to use the built in terminal when iTerm2 is so good.

Also nice is the TMUX integration.

Is the Keyboard Repeat Rate or Delay Until Repeat set to low? (System Preferences -> Keyboard)

Nope, that's something I take care of immediately on OSX. I think Terminal.app is just slow when redrawing the screen while scrolling.

How is vim + tmux any better than gvim + xmonad + terminals? Just out of curiosity, I may want to test this setup.

(I use vim+tmux+urxvt+awesomewm)

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?

Sort of.

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?


  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.

Indeed, it's very unfortunate that tmux doesn't run on windows (under cygwin).

It used to be very unfortunate, but J Raynor recently posted a working patch and I'm currently running tmux in Cygwin!


Cool! Thanks.

> Great to see some love for tmux.

It's not like tmux didn't get any love these days.

Am I missing something? What makes this "maximum-awesome"? This is your average vimrc with the regular plugins you seen in every vimrc over at GitHub.

Because it's Square and they're hip. Whenever they open the lids of their macbooks its you know... just awesome.

Not to mention it's not maximum awesome: CtrlP > Command-T and Vundle > Pathogen.

> 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.

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.

Also seems a little disingenuous to call it "open sourcing" when the vast majority of it is submodules of existing open source projects.

yea cmon, this is weak

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.

This writeup (not mine) I completely agree with: http://mislav.uniqpath.com/2011/12/vim-revisited/

Here's a similar post from me http://joelhooks.com/blog/2013/04/09/getting-to-know-vim/

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.

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?

What do you mean you could "never get it to work"?


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.

I prefer NeoBundle over Vundle. Lazy loading plugins is great.

Cool, so everything from tpope and a bunch of other garbage. Nothing new here, move along.

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.

Why is it silly? It's specific for OS X and OS X users already have ruby installed.

Because everybody has at some point tried to run rake on a new project and found some version incompatibility along the depth of the abyss^Wstack.

Hasn't bundler solved that particular problem for a few years?

Bundler isn't installed by default.

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.


Works on windows, linux, and mac.

I love vim.

Cool, I like that. Seems better than janus or spf13. Leave you some issues though.

I seem to be getting an error: Warning: Permanently added 'github.com,' (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.

This is a common git error, try http instead of ssh

git clone https://github.com/square/maximum-awesome.git

I get an error when running rake:

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.

that worked, what is the common error though?

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.

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.

Why remove vim-colors-solarized?

Ok, got this cloned and installed. If I'm moving from Sublime to vim, where do I go now?

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.

Type vimtutor at the command line to get started. Theres also a game: http://vim-adventures.com I thought was fun

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.

In the mean time, keep using ST on your projects.

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.

One minor nitpick is they use snipmate, but Ultisnips[1] is much better and actively maintained

1: https://github.com/SirVer/ultisnips

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.

Why is it a pain on Linux? Are you just referring to having a version of linux with +ruby or did you run into other difficulties?

Wonderful, looks like someone (@mislav and @christoomey) has already shaved this yak for me:


"Seamless navigation between tmux panes and vim splits"

So great. Off to check another random side-project off the list...

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.

It seems to be licensed under Apache 2.0, from the Git repo.

LICENSE is in root dir. It's Apache 2.0.

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].

[1] https://github.com/tpope/vim-pathogen [2] https://github.com/gmarik/vundle

Is there a way to uninstall this? Kill the symlinks and remove the appended .bak from old config?

Yep, just remove the symlinks and rename the .bak files. Opened an issue to cover this. Thanks! https://github.com/square/maximum-awesome/issues/37

Thank you for opening the issue. I should of thought of that.

These are all the features I wanted when I quit Vim for sublime text 2 about a year ago...

Do lots of people use let mapleader = ',' instead of Ctrl?

Also does anyone see where they are setting the /// to comment? Commentary uses gcc and I don't see it in their vimrc.

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.

"," is kinda becoming the "default" key for leader. After multiple years of using it, it has become very natural.

After doing anything for multiple years of anything I'm sure it would feel natural.

I used to use comma, but then I discovered comma's default mapping is actually quite useful[1] so I switched back to the default '\'

1: http://vimdoc.sourceforge.net/htmldoc/motion.html#,

I've never heard of anyone uses ctrl as a leader. I do use comma myself.

if you use hhkb(http://farm4.staticflickr.com/3322/3599528588_ce3e08503f.jpg) layout, it's rather convenient to use Ctrl as leader.

I went crazy, and it's a bit more tricky to pull off, but `q` is my leader key. Haven't looked back.

P.S. I mapped `Q` to recording Macros, since the default use of `Q` is completely useless to me.

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.

I find it fascinating that my set-up looks nearly the same already. :)

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.

I've been using vim for 19 years and still don't know how to use it properly. I try, then I always find some guru that does it better then I would.

I got it installed, I have installed multiple versions of XCode 5 betas and needed to run:

sudo xcode-select -switch /Applications/Xcode5-DP6.app

To get the command=T to compile

How? I executed: git clone git@github.com:square/maximum-awesome.git && cd maximum-awesome && rake

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.

wavesounds answered this below.

If you want to learn Vim while playing a game, try http://vim-adventures.com/

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.

What makes this difference from this vim distribution http://vim.spf13.com/ ?

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.

Does NERDTree work over ssh/sftp?

I remember having tried it once and abandoning because it lacked this feature (or didn't work out of the box).

No it doesn't and it only has a subset of the features already available in netrw which comes by default.

Really? I've always used it over SSH without issues.

NERDTree is totally devoid of any network-related feature.

If you are using it with something like fuse or expandrive you are not using it over SSH but on local files.

If you are using it in a remote Vim via SSH, you are not using it over SSH either.

If you did something like :e scp://foo//bar/ and see a directory listing you are not using NERDTree.


What's up with the name "Maximum Awesome"? Sounds teenagish. Anyway, I am a VIM lover and good to see this work.

Shared Clipboard: Just add "set clipboard=unnamed" to your .vimrc and you are done.

not a cool question but ... I wonder if it will install on windows without problems

It won't, it's mac os x only from the looks of it, which is kinda silly.

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"

luckily its open sourced and someone can create a Windows distro if they are so inclined.

spf13-vim is completely cross platform and has about even distribution across the different platforms of users.


How do you launch this after running rake?

`vim` from a terminal or use the MacVim.app in /Applications


Honestly, I agree. How is any of this news for any Vim user? It's the same old plugin everyone's been using for a long time now.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact