> Vim is the worst editor ... except all the other editors<p>Yes to the first five words, no to the rest. How many Vim users realize that some of its more infuriating behaviors can be traced back to its predecessor vi, which had to be able operate with a "paper terminal", essentially a roll of paper as a display, without wasting too much paper during editing?<p>And how do I know this? During my time at NASA designing part of the Space Shuttle, I was obliged to use vi and its immediate predecessor, with a roll of paper as a display. It was bad then, and it's worse now. The difference is there's no longer an excuse.<p><a href="http://en.wikipedia.org/wiki/Vi#History" rel="nofollow">http://en.wikipedia.org/wiki/Vi#History</a><p>Quote: "vi was derived from a sequence of UNIX command line editors, starting with ed, which was a line editor designed to work well on teletypes ... "
1) Dump Janus, add the plugins you actually want<p>2) True<p>3) :set paste<p>4) Then wrap it in a function<p>5) I've always found ctrl-p to be snappy actually. You can replace the matcher with ag or similar<p>> write the Vim configuration lines required to cause those files to be ignored. You have got to be kidding me.<p>Write a small amount of config once per project? It's no more complex than adding things to a UI<p><pre><code> set wildignore+=*/tmp/*,*.so,*.swp,*.zip
</code></pre>
6) No, vim can't, but plugins can. Ctrl-p has this feature (<a href="http://superuser.com/questions/390011/fuzzy-find-within-file-in-vim" rel="nofollow">http://superuser.com/questions/390011/fuzzy-find-within-file...</a>)<p>7) Stop just navigating with j and k.<p>> After reading this list, feel free to tell me how I'm doing it wrong on twitter.<p>You're not googling anything to find out the answer?<p>Also, because occasionally people haven't heard of it, get Gundo. <a href="http://sjl.bitbucket.org/gundo.vim/" rel="nofollow">http://sjl.bitbucket.org/gundo.vim/</a><p>Vim has a full tree undo, gundo makes it easy to navigate and see diffs between changes in code.
First of all, you have to dump Janus. It is bad for you. Learn to use stock Vim and gradually integrate plugins as needed. I recommend NeoBundle to manage them, as it is able to compile plugins if required.<p>I've been using vim for years and the only plugins I use are vim-airline[1] and vim-bufferline[2]. Of course, my editing needs may not be as complex as yours, but in reality most things you think you need a plugin for can be done with plain Vim. Feel free to check out my humble .vimrc[3] for some inspiration.<p>1: <a href="https://github.com/bling/vim-airline" rel="nofollow">https://github.com/bling/vim-airline</a>
2: <a href="https://github.com/bling/vim-bufferline" rel="nofollow">https://github.com/bling/vim-bufferline</a>
3: <a href="https://github.com/wolfcore/air-dotfiles/blob/master/.vimrc" rel="nofollow">https://github.com/wolfcore/air-dotfiles/blob/master/.vimrc</a>
> I've been using it full-time for just over three months now.<p>That's it: you just need to give it more time.
One simply can't expect to fully climb vim's learning curve in just a quarter of a year.
Your brain can't adapt so rapidly to so much new shortcuts.<p>> Jump to CSS selector. Jump to class. Fuzzy string matching. All these things and more are what I am used to. Vim just can't do them.<p>That's one example among others: there's vim's marking system for that, and your brain isn't just used to it now.
You find it slow, broken and not user-friendly, but it's not really, it's just that you need to give it time to master it.<p>My 2c advice: it you really want to like it, keep going and give it a full year.
If you think you can't give it more time, then Vim isn't for you and some commercial editors might do it.<p>I've been there, I know your current feeling. I'm a happy vimmer now but it hasn't been the case for something like a year.
There's a reward for real vimmers: you'll never need to switch anymore to another editor, because Vim is there, powerfull, opensource, free, multi-plateform, and you know how to use it smoothly.
The reason there's no project-wide find and replace in vim is that vim has no concept of a project. It's designed to be one of many tools, which works really well for some workflows and not for others. #5 is the same deal -- they're limited by the design of vim, and that design doesn't fit anything like TextMate's project search.<p>It would drive me _crazy_ if vim saved without me telling it to.<p>I think a lot of people suffer needlessly trying to make vim be what they want it to be, when it never is going to meet their expectations. You'd be better off trying to get those things you find useful about vim implemented in TextMate or Sublime than the reverse.
The issue of soft-wrapping text drives me <i>nuts</i>, not just with editors like vim but with programming-focused tools that can edit text in general. Github is terrible for this. Why isn't it possible to enable soft-wraps when viewing diffs? Hard-wrapping the text is not always a solution because it makes the text so much less versatile in terms of what you can do with it, unless you're willing to periodically remove the hard-wraps when you want to move the text somewhere else. Using markdown is not a solution because markdown is destructive; it eats blank lines and indentation.
Patience my dear friend, patience. I have been using Vim as my editor of choice for over a decade, I think I barely use 10% of its features.<p>Your configuration is always evolving - so don't fret if a plugin or a setting is not working for you, it just means its gotto go..<p>That said focus on `your productivity` over a religious choice of an editor. You actually got to live with it for decades to come. choose the right one which fits your use case.
I feel his pain! Especially the paste thing. I've been back and forth with vim for as long as i can remember. Finally decided to switch to Sublime on my desktop and keep a stripped down version of vim for my terminal needs. I feel like Janus is doing more wrong then good. If you want to get into the mindset of vim you should ditch Janus.
Yes! With the exception of item #5 and #6, I really strongly agree with these items. Vim's automatic indenting, in particular, just seems systematically broken.<p>On 5, ctl-p works great for me. I have it set up to use git in choosing what to ignore and it's plenty fast. On 6, I probably just don't know any better.
If anyone is looking for sane configuration — vim-sensible is the thing you are looking for! <a href="https://github.com/tpope/vim-sensible" rel="nofollow">https://github.com/tpope/vim-sensible</a>
Why limit yourself to a single editor? They're different tools, good at different things. It's <i>really</i> not that hard to learn, for instance, both emacs and vim. I've got both open right now!
As a regular Vim user, I don't understand why some of these features, like Ctrl-P are not implemented natively in C, rather than to have to rely on Vimscript or Ruby plugin.
Pasting the reply I gave in r/vim<p>Answer to some of the points,<p><i>Janus</i>: There are divided opinions in vim community about whether distributions should be used or not. I am on the latter side. But still for just checking out I installed Janus a while ago. Yes it is slow, but it turns out that it is as slow as my then `.vimrc` configuration. I tried to track down the problem. It is because of vim's blocking behaviour during executing external commands. When you write a buffer or switch to a buffer, syntastic, tagbar, powerline statusline, gitgutter, bufexplorer all execute external command. Vim becomes more slow when `.git` repository grow larger or when saving a large file. So how do you solve the problem? Remove those plugins and install Unite.vim[1] with vimproc[2] asynchronous library.<p><i>Files that change</i>: If you do external edits more frequently then I think it is time to rethink your work-flow. I think there is a common consensus that you should not run live edit in server.<p>* Indenting pastes* : There is a plugin for that [3] ?<p>* Opening files inside my project <i>: Last I checked command-t was damn fast, don't know where slowness comes form. Another alternative is `Unite.vim` `file/async` source. It is fast at finding files but goes slow while doing ignore-pattern checking. Without the checking it is DAMN FAST. The `phpcomplete/files` source I created for my php autocomplete plugin[4] easily list 4000+ files in seconds. If you want to list files obeying the patterns in the '.gitignore' or '.hgignore' files. Checkout my unite-file-vcs[4] plugin. It adds a `file/vcs` source that lists files by issuing `git ls-files` or `hg status -c -m -u` command for `git` or `mercurial` projects respectively.<p></i> Navigating inside files*: Checkout unite-outline[6]. It shows live output by parsing the current buffer. Unite.vim required. But it does not support css files right now. Adding support should be easy.<p>So the summary of the story. Move to `unite.vim` and friends ;)<p>[1] <a href="https://github.com/Shougo/unite.vim/" rel="nofollow">https://github.com/Shougo/unite.vim/</a><p>[2] <a href="https://github.com/Shougo/vimproc.vim" rel="nofollow">https://github.com/Shougo/vimproc.vim</a><p>[3] <a href="https://github.com/sickill/vim-pasta" rel="nofollow">https://github.com/sickill/vim-pasta</a><p>[4] <a href="https://github.com/m2mdas/phpcomplete-extended" rel="nofollow">https://github.com/m2mdas/phpcomplete-extended</a><p>[5] <a href="https://github.com/m2mdas/unite-file-vcs" rel="nofollow">https://github.com/m2mdas/unite-file-vcs</a><p>[6] <a href="https://github.com/Shougo/unite-outline" rel="nofollow">https://github.com/Shougo/unite-outline</a>