Another Emacs user here. The article is bullshit. If you use Sublime Text now, in a few years you will be using another editor (Atom?) and so on, or you'll become a dinosaur stuck with an outdated OS just because you need your favorite editor (similar to how some people still cling to WordPerfect running on DOS). On the other hand, Emacs and Vim are eternal: once you learn them, you're set for life, and you'll only get better at using them as the time goes on.
"Just use Textmate" or "Just use <Propietary Editor>" doesn't hold much water.
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.
To be fair, the OP says it is 23 years' worth of tips. I think the intended audience is probably people already using vim for 5+ years, who are ready for this stuff?
(As for "just use Sublime", I'd say just use Emacs :P -- but seriously both are probably OT for this.)
I program in both Windows and Linux environments, Visual Studio for the former and Vim for the latter. When I transition from Windows to Linux (and thus VS to Vim), I realize how much more I enjoy Vim. Even with VS's fancy intellisense and other similar features, I'm still faster in Vim. And every time I learn a new trick, I like Vim even more. And I've only been using Vim for a few years. I wonder how much faster and better I'll be after five more years of using it.
You should give a try to VsVim [1], a plugin for Visual Studio that provides Vim emulation. It supports a lot of features [2] and settings [3] and, most importantly, it is Open Source (it is also written in F#, which is nice).
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.
I used VIM as my only editor for something like four years, but I've got a full time .net/C# job now.
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.
> setting up the environment was always a pain for me.
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?
It's mostly to do with the various plugins that I use. I can pretty quickly get to syntax highlighting and editing with vim (read: instantly), but the other tools that I like integrating into my editing are where I hit a wall every time. Even with that I could sync everything via git or dropbox or whatever else that I wanted to do. It's just the fact that I have to dig through my mental notes to get it working. I also don't specifically have a VIM haskell environment to clone. (I don't have a sublime haskell environment to clone, either)
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.
Keep in mind that I said it's not excessively complicated or an extreme hassle. It was just less straight forward for me than using ST2 to get an immediate dev environment going with the haskell tools/integration I wanted (hlint, repl, error/type checking/hints, etc).
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.
There are certain features where this would be problematic. Things such as copy/paste to/from the OS clipboard, and a few extensions that require ruby support (since ruby isn't always available).
I completely agree that this is a garbage "tips" webpage... it's not tips, it's a bloody reference manual.
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.
On paper this works perfectly, in reality it doesn't.
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.
You can get sort of a preview by going into visual mode with 'v' and then typing in the motion command, and once you are happy with what was selected you delete the visually selected text.
I agree that its not very consistent here, because for a regex replace you would use a /c instead to get confirmation.
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.
I don't get it why someone would use a closed source tool to create open-source programs. Or why you'd use a closed-source tool for something as fundamental as editing a file.
While I enjoy using open source software on principle, in practice I care way more about usability and feature set. I understand that some people make a conscious choice to only use free and/or opensource software, but it's flawed to claim closed-source software is somehow unfit to operate, especially based on the "fundamental"ness of the desired action.
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.
I don't know whats the lifetime of these "trendy" closed-source tools since I was never a fan of them, I'd be worried that you loose more time by having to switch to a new tool each month. Exploring alternatives is nice, but you can't be doing that all the time.
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.
ST has been out for six years. That's not going to be comparable to emacs (mid 1970's - now) or vi/vim (1976/1991 respectively). I haven't jumped on Atom, or any of the other brand new editors because I want to know they'll have some staying power, but I don't think 5+ years is short enough for me to be concerned. I'm certainly not changing editors every month. I also do most of my editor exploration in my free time, and it's fun for me, so it's not really a waste of time (again, for me, in that context).
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.
I also care about being able to use the tool several years from now or on different distributions/OSes, etc.
With closed source you are locked to whatever the vendor provides, you can't just recompile it if it doesn't work on your OS anymore.
Also I don't have the time to reverse engineer and check the software for backdoors (not that I do that with the open-source one either, but at least its more obvious if something goes wrong there).
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.
If the vim developers announced next week they'd only support Linux, I'd keep using the Mac version until it becomes worse than a newer tool and then switch to that. The same is true of Sublime or any other text editor.
I'm not going to be forking an open source text editor if development stagnates.
Except that with an open-source tool you have the choice of using it as long as you want.
Once it is part of a distribution like Debian or Fedora it is unlikely that it gets removed just because upstream stagnates, and it'll keep running. If there are enough users the distros might even maintain patches of their own, or fork it themselves.
See for eg. tinydns, where the original is so old it doesn't even compile, yet there is a working version in Debian.
With closed source you don't have much choice except running an outdated chroot with an old distribution, or stop using it.
Because it doesn't matter. The closed source tool isn't going to hide stuff in your text file. And should they change completely in a way you don't like or stop updating you switch tools you aren't locked in since its a text editor.
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.
I think you could also ask the question in a different way.
What is the market for closed-source text editors? We have open-source text editors, and freeware(?) closed-source ones.
So who would buy a closed-source text editor?
(Talking about a text editor here, not an IDE)
So then why not just open-source it? Seems to me there are only drawbacks in keeping it closed.
I've paid for textmate and sublime text because they were better than their immediate competition for what I use them for. I know lots of other people who have paid for one or the other. I have a really nice tmux + vim workspace I use a lot but for unfamiliar codebases I find exploring a lot nicer in sublime.
[0]: http://delvarworld.github.io/blog/2013/03/16/just-use-sublim...