As a VIM user I am overwhelmed by this tips webpage which, despite in small font, requires 16 page downs to reach the end. "Just use Sublime Text"[0]
[0]: http://delvarworld.github.io/blog/2013/03/16/just-use-sublim...
[0]: http://delvarworld.github.io/blog/2013/03/16/just-use-sublim...
Vim is a hot mess in some regards, especially the scripting and plugin system. However, it's available virtually everywhere. I'm holding out hope that modern versions like neovim will address some of the legacy issues.
(As for "just use Sublime", I'd say just use Emacs :P -- but seriously both are probably OT for this.)
I can still use vim shortcuts comfortably and such, but setting up the environment was always a pain for me.
I was setting up an editing environment on a linux VM at home to write some Haskell, and started looking through vim plugins, etc. I got sick of it after five minutes because I didn't really want it to be a big thing, so I installed ST2 and the various haskell plugins. It took about ten minutes to get it running in a state where I could compile/build/repl from the text editor and have basic vim motions (which is really all I need from it right now). It also has a few things I really dig like the fuzzy command palette and multiple cursors (which are now available in a lot of editors, but ST2 still has the cleanest implementation that I've used so far).
I think the package manager/extensible side of vim is what really bugs me. Sure I can get in and figure it out, but I just don't want to most of the time.
Obviously this is a really superficial look at what vim has to offer and a very narrow use-case/problem; ymmv dramatically. I contributed a pretty solid chunk of change to the neovim project and I'm really a big fan of vim in general, but for that specific use case, I wasn't terribly happy.
I have never understood this argument. Copying my local .vimrc and .vim from one machine to another has always been enough to create an _exact duplicate_ of my environment. What's missing?
I'm not that it's necessarily excessively complicated; it's just not particularly straight forward, either. This could just be a failing on my part, but I haven't set up a vim environment in about a year, and there were enough confusing parts to do a little head scratching to get haskell plugins working to make me grab something else for now. With ST2, it's been about the same amount of time since I've set it up and only took around ten minutes to finish (that's with plugins to integrate HLint, compilation, a repl, type checking, etc).
Again, keep in mind that I said this was a very narrow use-case/situation. I'm not arguing that VIM is more difficult to set up for any case outside of the exact one I said. I'm not saying it is or isn't a generalizable point. I'd really have to do more digging to find out. What I am saying is that in this situation ST2 was easier to setup.
I'm also not arguing against VIM because of setup time/difficulties. Setting up a coding environment should be a relatively small chunk of the total time you spend using it to code. I'm just noting a relevant experience I had last night.
I haven't written anything here that says I won't use vim, or that I don't plan on using vim. I used it for years before, and even given those issues, I'm sure I'll end up using it again. I love the feel of the modal editing and how far people go with plugins/extensions.
That said, everything I noted can be fixed and made to go away. It's all accidental complexity. Package management, plugin management, and installation are all problems that don't necessarily have much essential complexity. If the Neovim project keeps traction, it looks like it'll go a long way toward making all of those substantially easier, or at least toward making it substantially easier to create solutions to those problems.
Either way I'll continue to use vim, but I'll also probably use ST2 a bit as well. The next time I set up an environment, I'll just be much more careful to set it up in a way that makes it much easier to migrate to another computer.
you keep a list of plugins in your .vimrc, beats dropboxing hands down.
They're things that aren't horrifyingly difficult to setup or remember, but they make it a little more complicated and don't feel straight forward.
They're not things that would keep me from using vim, but for this particular context, they're things that made me decide to just throw ST2 on the vm
It's always the first plugin I install in Visual Studio, I cannot work without it. It might not suit the needs of more advanced Vim users, though.
[1]. http://visualstudiogallery.msdn.microsoft.com/59ca71b3-a4a3-...
[2]. https://github.com/jaredpar/VsVim/wiki/Supported-Features
[3]. https://github.com/jaredpar/VsVim/wiki/Settings-Reference
HOWEVER: The article you linked is similarly bad. There are excellent reasons to use vim outside of "keep your fingers on the home row". Very common operations such as "delete the next 30 lines", "Move these 10 lines to just after line 150" and so on are much faster in vim and this is why I use it. I don't use it for hjkl (which is only there because of the presence of arrow keys on those specific keys in the 80s) and I certainly don't use it so I can write plugins in the god-awful vimscript. Although it's nice these things are there, that is really not why I use vim.
No, I use vim because it has a comfortable set of basic keybindings, which you will use a lot while you get used to the more complex ones.
Besides, it's not so much about using vim, but about using a good GUI editor with vim mapping.
A lot like Regexes. The first n attempts at a regex always fail, and fail for human reasons - I didn't spot that the pattern I'm matching on actually appears earlier in the writing, the pattern has a typo but I spelled it correctly, the pattern used a unicode character that looked like an apostrophe, etc.
And Vim composability suffers in exactly the same way. "Delete back eight words" works on paper, but eight words isn't a thing you can glance at, it means stopping and counting - especially not if it goes back over a linewrap. And does what about the word boundaries? If the cursor is in the word, at the end, at the start but still has to cross the word boundary to get to the previous word?
Combined with that, the way Vim commands have instant and unbounded effects means that the wrong command or a misspress of a key, and suddenly there's a huge change to the text and you don't know what happened. This leads to the effect where even if a change looks right, if it was a big change ("add a comma to every line just before the last word") needs a lot of careful verification to make sure it worked as intended.
In real world use, almost everything I try to do in Vim outside the everyday patterns of habit, takes enormously longer, works less well, is more fiddly and stressful, than 'just' doing it by hand or in Python.
Regarding the 'I pressed the wrong key' problem there is undo (and if you enable undofile you can undo even after saving or reopening the file), and there is git history.
Having said that I agree that there are often situations where automating something (or using a more complex Vim command) would take more time than doing it by hand.
As far as a business case goes, there's no real "vendor lock in" with a plaintext editor like this. You can always switch to something else and your files will be fine/the same. You're investing (potentially non trivial) time to learn using it, but it didn't take me long to learn ST2 to a depth that made it really handy.
I will say I'd buy a lot more into that argument for people who develop plugins.
That said I can respect the "open source" only mindset. I'm just not sure I'm that concerned about it in this particular case.
For example there was a time when I switched a Linux distribution each month, then at some point I realized that it is getting me nowhere: I didn't know either of them in-depth or how to deal with their specific problems. So then I made a choice: I'll use only Debian, and actually learn about how to deal with problems when I encounter them, instead of jumping ship to another distro.
Its the same with text editors, I eventually settled on Vim (for a long time without any plugins), then started using plugins as well.
Sure every now and then I check what new alternatives are out there (for example there are some interesting ideas in http://leoeditor.com/ but not really comparable to Vim), but closed-source tools are never on my list. I only ever heard about Sublime Text here on HN, and even then for a long time I thought its a Mac only tool.
But with closed-source tools I just wouldn't have been motivated to stick with any of them: if there were problems with it then I wouldn't know how to work them around, or implement missing functionality, not to mention I wouldn't trust them to begin with etc.
I should say that I can't really settle on VIM right now because I'm doing full time .net work at this point. I still use it reasonably often when I'm mucking about in C at home, and I used it as my primary editor for at least five years prior to that, but my use-case was me trying to get a decent haskell environment up and running on a fresh linux VM as quickly as I could. ST2 worked really well for that.
If you work on closed-source software then you probably don't care about this / doesn't matter there, but as someone who spends most of his time working on open-source software I definitely want my editor to be open-source.
I'm not going to be forking an open source text editor if development stagnates.
With closed source you don't have much choice except running an outdated chroot with an old distribution, or stop using it.
And honestly even with open source if the main devs stop updating or doing something you don't like you're time is almost certainly better spent doing what you're doing on a different editor or the old version then taking over development on yet another text editor.
So then why not just open-source it? Seems to me there are only drawbacks in keeping it closed.
That blog post reads like a rant, do the author really know anything?