
The Ultimate Vim Distribution - edu
http://vim.spf13.com/
======
jlgreco
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...

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

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

~~~
adambyrtek
> 'hlsearch' should definetly be the default

Not really. I often use (incremental) search just to move around, and I don't
want the highlight to distract me, especially with a really common pattern. I
would consider using it if the highlight disappeared immediately after the
search is over, but as far as I know there is no such setting, so I only
enable it from time to time.

This just proves that it's really hard to agree on defaults.

~~~
jlgreco
Well, the highlighting doesn't start until the search is over (you've pressed
enter). I use this to clear the highlighted results when I am done with them:

    
    
      nmap <C-h> :noh<CR>  
    

Maybe there is a way to make it automatically do that after searching with
some sort of timeout. Not sure.

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

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

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

~~~
erydo
First: I'm not recommending anything—I'm asking a question. This isn't my
practice but it's important to play devil's advocate sometimes.

Second, the question was not whether piping to shell is a good way of doing
installations. The question was whether it's actually worse than the common
method of offering up an untrusted downloadable executable.

Many (or most) consumer software downloads that you'll find for Mac or Windows
don't meet _any_ of the criteria you specified (which I agree are good
criteria). But that wasn't the question: Is it actually worse than offering an
untrusted executable? People don't seem to complain about those as much, but
to me they seem equivalently bad.

~~~
dredmorbius
At the very least, pipe-to-shell means you're left without an audit trail,
_if_ you're actually practicing that method.

With a downloadable executable or installer, I'm left with a file that I can
save, checksum, scan for vulnerabilities, and/or refer to at a later date
should I find that there are concerns I didn't discover initially.

curl-pipe-bash, _especially_ in the absence of SSL/TLS, leaves me vulnerable
to injection attacks, as well as invisible changes to the installer (so I
don't know whether or not things have changed if I'm trying the same process
later).

It's a very, very, very bad idea.

My prediction: this will all end in tears sooner or later. I'm actually hoping
for sooner just so we can put an end to this foolishness.

As for Windows: I don't play there often, but my understanding is that most
executables are now signed, so that the "download random binary from arbitrary
website, run as Administrator" practice is at least very slightly less batshit
insane than in the past.

~~~
lowboy
While I agree 100% with your advice for mission-critical servers, for a dev
machine I don't see the problem with the ease of curl -> sh. It takes "very
very very bad idea" down to "you probably should at least check out the
installer script first".

~~~
dredmorbius
Where do you think that code for mission-critical servers gets developed?

There's a pretty scary amount of iffy public code that ends up on mission-
critical servers. I could outline some chains of connection, but briefly: it's
very easy for someone's cheesy little website to become a significant player
in another organization's processing.

That "website" you're going to likely runs not only on multiple servers, but
in multiple datacenters across multiple organizational borders: core site,
sales, support, order fulfillment, marketing analytics, web analytics, email,
messaging, social integration ....

The best way not to get into bad habits on your production, mission-critical
systems is to not allow them anywhere else.

Granted, this is a Vim suite, but I'm seeing similar brain death in far too
many corners.

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

~~~
olalonde
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
A couple of lines in your .vimrc and boom you have that and more.

~~~
olalonde
... or one bash command to install Janus.

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

~~~
wahnfrieden
How is vundle worse?

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

~~~
wahnfrieden
If I'm not mistake, vundle doesn't use git submodules, pathogen does.

~~~
jlgreco
Pathogen just uses a directory tree. Some users decide to use git submodules
in it.

------
alwillis
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-...](http://vimuniversity.com/samples/your-first-vimrc-should-be-
nearly-empty)

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

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

------
nshankar
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
Is Martin Grenfell scrooloose the author of NERD and syntastic, or just copied
them onto github?

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

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

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

> E117: Unknown function: fugitive#statusline

> E15: Invalid expression: fugitive#statusline()

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

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

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

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

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

~~~
keithpeter
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'.

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

------
nvmc
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_slack
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
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_slack
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'

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

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

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

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

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

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

~~~
owenjones
You can update your bundles straight from the command line with:

vim +BundleInstall! +qall

Vim still opens but could be useful if you're trying to automate vim somehow.

~~~
wahnfrieden
Yeah. I'm just citing the only reason I've heard, which is that invoking vim
just to update a plugin is gross. Which is kinda true - what happens if your
vim config is in some bad state and doesn't start properly, your update
process breaks unnecessarily (odd coupling to have). Definitely edge case-y,
but a tradeoff anyway.

