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