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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I'd agree with you on hidden but... the Vim defaults are (generally) the most vi-like settings, which makes some amount of sense. At the very least it keeps people from squabbling about what should be the default.
OTOH, the default vimrc has a bunch of stuff turned on and tweaked depending on your platform. So that could be a good venue for turning on some of these new, Vim-only features. That may sound like splitting hairs, but I think there's at least a bit of difference between "on by default" and "set to on in the config mkvimrc creates".
Eh, my thought is that 'vi'/'vim -C' should remain conservative but that just 'vim' by itself should turn on the sensible stuff. Certainly 'hidden', if not the more cosmetic searching stuff ;).
Some of the defaults are just plain harmful to people trying to get started. 'nohidden' is awful if you try to use buffers without knowing about it, and I don't think I've ever met anyone who wasn't infuriated by 'backspace' defaulting to "".
I'm not so much a fan of the platform tweaks, since you can't expect each platform to make the same ones. If you learn on one and just assume those settings will be the same everywhere, it can be very annoying when you switch to another system only to discover that your .vimrc isn't getting you the same behavior. 'backspace' is a particularly egregious setting this happens for often I find. It would be better if all systems left backspace="", so that everyone knew to add it to their .vimrc's.
In case it isn't clear, prezto is a fork of oh-my-zsh which has basically been rewritten bit by bit to make everything much cleaner and saner. I highly recommend it. The history-substring-search and syntax-highlighting modules are brilliant. You will be the envy of all your friends and neighbours.
I've been using oh-my-zsh and the startup is really slow. I hear prezto solves this. How do i upgrade from oh-my to prezto? No one seems to answer that ?
I've just made the switch after finding out about prezto from this thread. The reason the upgrade process isn't documented is that, unfortunately, there isn't one. You just have to remove oh-my-zsh and install prezto, then move over any modifications you've made manually.
That said, it wasn't much work, and I've been using it for the past couple hours and I really like it!
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.
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.
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.
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.
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".
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.
Please supply the package name, version and the output of "apt-cache policy <pkgname>". That should list where the trojaned package came from (presuming no changes to
sources.list, etc., etc.).
Packaging systems leave audit trails. Even if you get hosed, you can often figure out where and how, and take steps to both correct the upstream issue and identify and mitigate any locally affected systems (generally through a wipe/reinstall if you've got to this stage).
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.
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.
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.
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.
I also use this daily, and have the same problem. I suppose this speaks to the weakness others have expressed (in using a premade configuration setup vs. slowly rolling your own), but I have otherwise found spf13-vim very useful.
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.
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.
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.
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.
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...).
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.
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.
Why would you need submodule support with vundle? With vundle you don't even need to have your .vim directory as a part of the 'dotFiles' repository - it just accepts a list of plugin (github/vimscript/whatever) urls that you want to install.
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.
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.
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.
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.
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.
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.
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 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.
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'.
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.
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).
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.
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.
While I also wish Vundle weren't as wedded to GitHub, I still find it to be the better of the two tools. Plus, Vundle can also use the Vim Scripts repo as a source, so it's not strictly tied to Git/GitHub.
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.
I previously used pathogen + git submodules .. It was very challenging to manage and much harder to keep up to date.
Vundle has proved a significantly better system for keeping things managed and uses the exact same approach and code as pathogen. It's hard to criticize vundle and support pathogen since they are so similar.
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.
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...