The Ultimate Vim Distribution

http://vim.spf13.com/

by edu • 14 years ago

153 88 14 years ago

vim.spf13.com

seanponeil• 14 years ago

This seems very similar to Janus (https://github.com/carlhuda/janus). It has almost the exact same bundles and setup process.

spf135• 14 years ago

See my comment above. It's similar. Some material differences are that It doesn't require Ruby on the host system to install. This is a huge difference.

It only requires git and vim to install. The bundles have some similarities, but again key differences here are that none of these bundles require vim being compiled with +python or +ruby support.

Lastly it's focused working well for editing any language in any OS.

No criticisms of Janus, it's a good project, just took a different approach to the same problem.

jlgreco8• 14 years ago

I have said it before here when people have discussed packaging up Vim stuff, and I stick by it: I really don't see this taking off.

Switching to using this does not appeal to me, an existing Vim user, and I think I am not an exception. If this does something new that I like I'll gladly throw that part into my setup, but there really isn't any reason at all that I can see for wanting to use this.

I don't think this is good for new Vim users either. If you are new to Vim there already is no shortage of things to learn (I think GVim steps up in this role nicely). Throwing more things into the mix isn't going to help a thing. And as you (slowly) pick up more and more of stock Vim, you are going to naturally build up your own setup. Before you know it you'll be at the same point that I think existing users are generally at.

This all said, I'm also a zsh user who cannot fathom why oh-my-zsh is popular...

Symmetry2• 14 years ago

In term sof new stuff that's true, but there are a lot of things that modern plugins provide that obsolete the traditional way of doing things. For instance, people using EasyMotion never have to worry about counting how many words ahead they're moving and then typing c69w or whatever. And likewise, there are some things that everybody should have in their .vimrc, like incremental search, and it doesn't make sense to learn to use the old way first.

jlgreco8• 14 years ago

There can absolutely be improvement on some default Vim settings. 'hlsearch' should definetly be the default, and I think it is a crime that 'hidden' isn't. There are easily dozens of other examples.

However I think these should be made defaults in Vim itself, not in some grabbag of stuff we hand new users on their way in. I think it is important that every Vim user knows exactly what ways their setup differs from the default, and this is only feasible if every difference from the default (the real default) is made by the user.

johncoltrane4• 14 years ago

I tried it for a couple of weeks but I couldn't wrap my head around EasyMotion. `set incsearch` and `/foo` are all I need.

jeremyjh• 14 years ago

I think I agree to an extent. I am glad that I pieced my vim setup together because I know exactly what each part of it does, but the fact is I selected a lot of the parts because they were included in a distribution I read about or a blog article I read. Still, I did not add them until I knew I wanted them and I learned them one at a time.

Interesting you mention oh-my-zsh. I DO use that, but that distribution I think encourages you to turn on and learn the plugins as you actually need them - they are not turned on by default. So I've gone through a very similar process with them.

neeee• 14 years ago

Have you looked at prezto[1]? It encourages forking and in-place editing strongly, and everything is a module.

[1]https://github.com/sorin-ionescu/prezto

jlgreco8• 14 years ago

I'll check that out, thanks. My zsh setup has been pretty stagnant for a while now, probably about time I gave it some love.

tammer• 14 years ago

Here here. The only vim-related thing new users need to know about is vimtutor.

These tools are designed to be complex so as to not limit the user. If you throw everything at them at once there's no way to understand how everything fits together.

I see the same problem in suggesting that people start learning zsh by installing oh-my-zsh.

njharman2• 14 years ago

This.

Vim is vim is popular because it is a highly configurable tool that each user can tweak to be just right.

But,

1) things like this will get new people using vim. Without usage, code rots.

2) things like this teach me all sorts of vim I did not know.

In re 2: I really want to see their vimrc file without having to install this.

bti• 14 years ago

re 2: Up on GitHub

https://github.com/spf13/spf13-vim

wonderzombie• 14 years ago

For my part, I used Vim for maybe a decade before switching to SublimeText 2 approx. four to six months ago. It was pretty close to impossible for me to get all the plugins and functionality I wanted set up correctly in Vim. Conversely ST2 ships with everything I want and with approximately zero config, so I jumped on it.

I don't have much intention of going back, but it's still useful to have an editor I can run in a terminal, so I installed UVD. We'll see how it goes, but I like the idea of a curated setup where I just drop in my custom crap from my old vimrc and call it good.

That said, I agree with the larger point that it's hard to see whether it will take off. But if it's easy for them to maintain it and they're scratching their own itch, it seems like a net win.

batgaijin• 14 years ago

Sort of related: I only use Emacs today because of the Emacs starter kit.

Maybe it's particular to Emacs, but I've found that the defaults are often terrible, and half of all tutorials I see for _anything_ are about changing the default case.

Flenser• 14 years ago

Which one?

This one: https://github.com/technomancy/emacs-starter-kit

or this one: https://github.com/eschulte/emacs24-starter-kit

I've been using and configuring emacs for a few weeks now. Is it worth starting again with one of these or will it move too much cheese?

rat872• 14 years ago

I download oh-my-zsh(or the fork Prezto), pick a theme, tweak 1-3 settings, load my custom PATH, and I'm in excellent shape. I have a shell that works great with little work.

rat872• 14 years ago

Similarly with vim, I don't know most of the whizbang vim command combinations and don't use it much outside of short console edits, but gvim with its syntax highlighting + splits(created and selected with a mouse) + lots of plugins (mostly installed with pathogen):minibuffexplorer + ctags + tagbar is a fairly useful combination without much custom configuration.

Symmetry2• 14 years ago

Wow, that's a lot of good stuff. I'd recommend this to anyone starting with vim.

keithpeter• 14 years ago

I think that is the point. Anyone starting now can make their own decisions and approach an enriched distribution like this with new eyes (beginner's mind?)

Anyone else might just need a 'standard' vim because they work on remote terminals into servers on which custom packages cannot be installed, or perhaps they are used to the 'old ways'.

johncoltrane4• 14 years ago

I wouldn't recommend it to anybody, even less to beginners.

$ vimtutor and how to use the documentation, that's what I'd recommend to beginners.

andyl• 14 years ago

Like everything except vundle. (I use tpope's pathogen) Pre-packaged vim on github is a very nice way to distribute.

mcrittenden• 14 years ago

I'm curious as to why you (or anyone) would prefer pathogen to vundle? Vundle just seems like pathogen except with less manual work.

jlgreco8• 14 years ago

I switched from Pathogen to Vundle, at the prodding of people on HN, and I can't say I am all that thrilled about the difference. It basically does what Pathogen does, plus it does a bit more. The issue is that the "bit more" that it does just doesn't seem... polished.. to me, and covers things that I never found troublesome to do manually anyway. I'm not going to switch back (since it does what Pathogen does there isn't a reason), but I don't think it is better, just different.

wahnfrieden4• 14 years ago

Vundle is strictly better unless you automate your software updates and want to be able to update your vim plugins without having to launch vim to do so. Pretty tenuous but maybe some sysadmin-inclined people really prefer this.

johncoltrane4• 14 years ago

1. I switch to another tool if and when I have problems with my current tool. Because Pathogen has served me well for the last two years there's no reason to switch to Vundle or some other plugin manager.

2. Vundle is too heavily Git/Github-centered for my taste.

JosephRedfern2• 14 years ago

Installed it, but now I'm getting this error when starting vim:

> E117: Unknown function: fugitive#statusline

> E15: Invalid expression: fugitive#statusline()

spf135• 14 years ago

please report this issue in Github. I'd be happy to help.. It sounds like fugitive is being triggered in a directory that isn't being tracked by git... but it would be better to continue the dialogue on Github.

JosephRedfern2• 14 years ago

OK, Great. I'll report it later on tonight.

exogen• 14 years ago

I realize this is a different project, but since it looks similar: installing Janus was the worst decision I ever made while looking to improve my Vim experience.

It actually made Vim worse, sometimes by just slowing things down, other times because of the lack of quality control in the bundled plugins. One plugin actually caused data loss many times – it completely froze the editor when a certain syntax pattern was typed. All with just the default Janus settings.

To that effect, I hope quality control in spf13 is really, really good.

olalonde2• 14 years ago

I think you are an exception. I can't get anything done with vanilla Vim (no smart indentation for instance) and install Janus anytime I need to use Vim on a new shell.

sigzero• 14 years ago

A couple of lines in your .vimrc and boom you have that and more.

alexkus2• 14 years ago

I've used vi/vim for ~20 years (I have memories of using it in '92 when I had an Amiga B2000) and I've never installed a single extension/package/what-not.

The corporate development environment I'm in means it's a huge amount of work to get anything installed on a wide range of platforms (6 different OSes not including Windows) and on a large number of machines. For various security reasons, my home directory is not shared amongst all of the machines, which could have made it easier.

However, the main reason is that I often go to customers to solve problems and I have to use what they have installed. I can't go asking someone to install vim and a bunch of extensions on their production servers just to make me feel comfy; I have to rely on the lowest common denominator set of basic tools that are usually installed; vi (even ed), sed, awk, sh (can't even rely on bash being installed).

Don't get me wrong, I've nothing against people using vim with a whole bunch of extensions, it's just not for me.

But not being proficient in the basics can be a bad thing, especially when it's usually a tricky/pressured situation where you're left without your favourite dev environment.

spf135• 14 years ago

This is my project. I was surprised to see it on HN today. It has a lot in common with Janus on the surface. IMO Janus is also a good project.

Where it differs is spf13-vim is focused on cross platform dependency, keeping with vanilla vim feel and having no external dependencies (with the exception of git).

My understanding on Janus is that it focuses on Ruby (spf13-vim supports Ruby well, but Python, JavaScript, PHP, Shell, Scala and a bunch more as well). Janus includes many plugins that depend on Vim Ruby support and is definitely focused on the MacVim platform.

My goal was a Vim configuration you could run anywhere whether Linux, Mac or Windows to efficiently develop in any language.

Hopefully you will find the quality control is good, general feedback is very positive. If you find issues please submit a issue on github or even better a pull request. You can see that I'm very responsive to pull requests.

vessenes• 14 years ago

Thanks for spf13 -- I use it every day, on Mac and Linux, with Python.

I do have one persistent, annoying problem with it, though, since I've got you here -- inserting close braces/parens OFTEN doesn't work with whatever plugin you use for the auto-closing. How do I turn it off? I remember trying to get rid of it, and failing miserably.

FuzzyDunlop• 14 years ago

I agree with the sentiment, and it's exactly why I switched from a ready made emacs setup to a custom-rolled config.

Most of the stuff bundled in it isn't really necessary, and just makes it harder to understand the clean environment if you're new to it.

Even though it's more work, it's nice to know exactly how you're configuring your own environment, and you get to learn more about it as you do configure it.

To that extent I'm not even a fan of emacs' new package manager.

DiabloD32• 14 years ago

I don't get why this is loaded down with useless plugins... if you're using ctrlp/command-t, you don't need nerdtree. Vundle isn't as good as pathogen, neocomplcache isn't as good as supertab + clang_complete, and it lacks gundo, rooter, ultinips, and maybe other things.

https://github.com/Diablo-D3/dot_vim

wahnfrieden4• 14 years ago

How is vundle worse?

DiabloD32• 14 years ago

I dunno, I had problems trying to make it do something, but I forget what. I almost want to say it was git submodule related, but it was like a year or more ago.

phleet• 14 years ago

I use vim extensively and I use both Ctrl-P and NERDtree. Many, many people I know use both.

They serve difference purposes for me. I use NERDtree to create/rename/move files and quickly change my CWD (looks like you use rooter for CWD). I use Ctrl-P to switch buffers and quickly open files.

On the note of neocomplcache, supertab + clang_complete doesn't provide as good support for languages outside of C++. Working with python a lot, neocomplcache works better for me than supertab. The actual functionality of it isn't quite the same either.

Saying vundle isn't as good as pathogen is silly, because vundle is a layer on top of pathogen-like package management. Everyone I know who uses pathogen has to use some system on top of pathogen to actually install their list of vim plugins whenever they switch machines (bash script, ruby script, another vim plugin...).

akurilin• 14 years ago

I prefer vundle to pathogen, it's really brainless to use.

qznc• 14 years ago

Thanks for suggesting rooter. Did not know that.

xyzzyb• 14 years ago

I switched to vundle from pathogen and I'm much happier for it.

They're both great, but pathogen requires that you setup the plugin directories yourself which makes keeping the plugins updated a pain since you either set them up as their own git repos (which you have to remember to update) or git submodules if you're trying to maintain a repo of your entire configuration.

Vundle just requires a few lines in your config and is already git/github aware and just does the right thing. It's also trivial to see at a glance what I've installed.

Uninstalling a plugin from vundle is as easy as removing the line in the config and telling vundle to update.

https://github.com/sdball/dotfiles/blob/master/vim/vimrc

theoreticalee• 14 years ago

I just installed this last night. I'm comparing it with https://github.com/fisadev/fisa-vim-config

Right now, fisa is slightly ahead because it is a bit faster.

alwillis• 14 years ago

Distributions like these are good for people who just need to use Vim, not necessarily for people who want to learn Vim. It's often better for people to add plugins and update their vimrc file as they learn Vim and figure out what their Vim style is.

This article helped me with my 2nd attempt to learn Vim: "Your first vimrc should be nearly empty" http://vimuniversity.com/samples/your-first-vimrc-should-be-...

njharman2• 14 years ago

> curl http://j.mp/spf13-vim3 -L -o - | sh

I'm stunned that anyone would pipe from internet to shell. No SSL and redirecting just make it easier for the bad guy.

It makes me angry that people are promoting this as an install method. Like suggesting your first name as a good password.

spf135• 14 years ago

If you have any concerns there are also manual install instructions.

SSL is a good idea. I should absolutely switch over to that.

dredmorbius5• 14 years ago

Here's my suggestion:

Post the manual installer methods.

Post checksums.

Sign your checksums.

erydo2• 14 years ago

Ignoring the SSL bit, from a security standpoint is piping to the shell really any different than saying "run this installer application"? Either way you're allowing the source to run arbitrary commands on your computer.

dredmorbius5• 14 years ago

Yes.

For me to trust an installer, implicitly, it's best for it to be part of my software distribution's package management system.

This means that the package is signed and checksummed, it's included in the distro's bugtracking system, and is being downloaded from a known set of mirrors.

Your next best option is to provide a download, checksums, and signatures, with a well-signed PGP/GPG key. At this point I can at least verify that the content is what you claim it is (whether or not that's something I plan on running is quite another matter).

Even a git repo provides a SHA1 checksum of a given commit that I can reference.

By recommending I curl-pipe-bash something, you're sending me a FLAGRANT signal that your security practices are somewhere well north of batshit crazy.

I ran into this while evaluating RVM (Ruby enVironment Manager), which itself turned out to be a requirement (or at least facilitator) for properly using Ruby for, of all things, supporting a Chef (configuration management tool) infrastructure. So ... in order to get a better handle on our server infrastructure ... the recommended and default practice is to install crap via curl-pipe-bash.

That cost us about six weeks of going through the damned installer and its effects (documentation is really poor) with a very fine-toothed comb. And I'm still not happy using it.

jlgreco8• 14 years ago

The problem is that it blurs the line between what is safe, and what is not safe.

It is basically the difference between telling your users to do:

  wget example.com/some_script.sh ; chmod +x some_script.sh ; ./some_script.sh

and:

  wget example.com/some_script.sh
  chmod +x some_script.sh
  ./some_script.sh

A good engineer will tell you that those two things are exactly the same. The reality however is that they really are not. The first is a single cohesive unit of work, from the perspective of the user. It is "easier", even though you could copy/paste the second example just as easily. The second is clearly three units of work. The story is the same, but the runon sentences have been removed. The user is almost forced to, subconsciously, ponder each step: First we download this, then we run it. Why the separation?

It is about reenforcing deliberate actions. Discrete options give the user time to interject their own thoughts.

If that isn't something that we value, then we should stop half-assing it and just give wget or curl an 'execute' flag.

ggchappell• 14 years ago

Figlet sighting. Standard font, output edited a little. :-)

johncoltrane4• 14 years ago

Yet another set nocompatible. In "The Ultimate Vim Distribution", no less.

I can't understand why anybody would want to use that kind of "distribution". All the vimrc tweaking and plugin dance is actually very beneficial in the first few months because it forces beginners to learn a lot of basics and, above all, how to use the help. And, well… experienced users already have a vimrc tweaked to hell and their own set of plugins.

papaver• 14 years ago

the problem with packs... there is so much stuff to ingest, most of the stuff goes unused.

learn to use default vim first. then start adding aliases and macros as need to speed up things.

most of the plugins mentioned are useless to me. default vim is super powerful as it is.

why try to fix problems that aren't there? the beauty of vim is the unique way each user approaches it. every time i sit next to a vimmer i'm like 'how the hell did you do that!" same thing that happens when vimmers watch me code. ive been using vim for 6+ years now, i still haven't even got close to using 10% of it, and i daily use around 50 or so key commands.

nvmc• 14 years ago

I never really had a problem with configuring vim and installing plugins manually. This seems like it'll make vim more daunting for new users, while getting in the way of experienced users.

jason_slack2• 14 years ago

I dont like how the current line is always 0 and not the actual line number. How do I fix that? I have never seen this elsewhere.

I must admit that this distro will help my workflow.

wladimir• 14 years ago

That option is called "relativenumber". You can go back to normal numbering with "set number". I find it very useful myself, though, to quickly move to a line with relative commands such as 10j, or select ranges, delete a number of lines, etc... The only case in which I really need absolute line numbers is when jumping to a line for an error message (luckily G key will always use absolute line numbers).

jason_slack2• 14 years ago

Do you know what to change in .vimrc to stop using relative number by default? I looked around and nothing with "relative" and I do see a 'set nu'

humiaozuzu• 14 years ago

I'm using this one which is much better http://github.com/humiaozuzu/dot-vimrc

nshankar2• 14 years ago

Ctrlp link is broken - use this: https://github.com/kien/ctrlp.vim

fine• 14 years ago

I think this is fantastic. For beginners and not so much beginners, it is a great way to start with a very complete system for developing and build on/customize it the way you like. You don't lose any customization power as others have said. I just renamed my .vimrc to .vimrc.local and that's all, everything is working plus I earned a lot of extra-plugins that I didn't even know about.

I love it, thanks to the autor/s

nshankar2• 14 years ago

I personally swear by https://github.com/scrooloose/vimfiles.git installation. It doesn't go by some fancy name but does its work outstandingly. I have added to its vimrc wherever it deems fit. ASK HN: I am looking out for jumping out to a CSS selector in a css file from the HTML file I am editing for quite sometime in one key. Please see if you can guide me on this.

trhtrsh• 14 years ago

Is Martin Grenfell scrooloose the author of NERD and syntastic, or just copied them onto github?

symmetricsaurus• 14 years ago

I think it is good for showing some different plugins and configuration options available in Vim. I think I will use the the included .vimrc file and plugins to look at to get ideas for my own .vimrc. The default in the distribution makes my Vim look like a christmas tree, which I don't really like.

The Ultimate Vim Distribution

Related Stories