[mpk]

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!

[adamesque]

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:

http://stevelosh.com/blog/2010/09/coming-home-to-vim/

http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...

…and then I needed a mostly-well-documented distro like Janus (https://github.com/carlhuda/janus) to ensure that my productivity wouldn't take a huge hit those first few weeks.

Some folks can probably go all-in cold turkey, but I needed the training wheels.

[johncoltrane]

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.

[Legion]

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

[eksith]

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

[commandar]

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

[jvoorhis]

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.

[textminer]

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

[IgorPartola]

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.

[cgdangelo]

> 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

[johncoltrane]

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

[karmajunkie]

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

[johncoltrane]

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

[karmajunkie]

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?

[adiM]

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

[chongli]

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.

[59nadir]

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

[anaphor]

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.

[jlgreco]

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.

[typicalrunt]

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.

[adiM]

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.

[fhd2]

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

[eliasmacpherson]

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.

[enduser]

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

[efnx]

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

[tokipin]

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

[INTPenis]

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.

[mattschmulen]

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

[ElongatedTowel]

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