Seriously, to me it solved all my issues with Vim. Now I have several processes attached to my "Evil", heaps of plugins installed, yet everything blazing fast. And the configuring in elisp started as a little awkward, but now it feels so much more sensible then vim-script (especially knowing that development on Emacs started ding the 70s).
With Evil I can say that --for me-- the Vim/Emacs fight is over:
I was a long time emacs user, and switched to Vim due to typing pain. Even with Evil, I can't see moving back. Vim + Tmux + YouCompleteMe > Emacs. There's just no comparison. No Emacs shell will ever be as good as zsh, and there's always some latency for some reason when using shells running in emacs. And, there's no youcompleteme.
Evil still lacks q: and q/ for command and search history editing. Really pains me that they haven't implemented this yet. There's also nothing that 100% replaces the CtrlP plugin for Vim on Emacs.
And people complain about UI discoverability in vim, but the fact is if you know how to quit out of vim you will sooner or later bump into the command history; if you experience rogue-like joy in the at this moment you know vim was meant for you.
I don't know if it's by default but Vim also saves search / command history across sessions. So if you quit or accidentally kill the terminal and open Vim again, that history will still be there.
Yeah setting up fuzzy finding on emacs is a huge pain. It's not a hard problem to solve, so maybe if I end up making more use of evil I'll try and write something although elisp is not fun. I currently use helm, ido and projectile and it only kind of works as good as cntrlP or command+T on textmate or sublime text.
I've been thinking about trying this out for a while now. I just haven't mustered the courage to make the jump. It would be great if there was a tutorial focused specifically on helping vim users who know basically nothing about emacs make the jump.
With that said, is it really worth it if I already use vim along with tmux? This is probably what has kept me from trying out emacs before. Vim isn't an IDE, but with appropriate use of tmux it feels like it can be one.
It's hard to say whether it is worth it. Is there anything you're missing from Vim + Tmux?
The best thing would be to just check it out if you're ever in a playful mood but the chance is pretty big that just playing around with Emacs for an hour will not be enough to convince you to switch.
Feel free to mail me about Emacs so I can help you as Vim user on the way and if you keep notes you can write that "Emacs for Vim users" guide that you asked for.
I can't wait for neovim. The promise of a better scripting language, better remote editing experience, better native GUI support on non-linux platforms, and better IDE integration has me itching to try it out.
Vim has seen active development for over 20 years and is available almost anywhere due to this. Reimplementations are announced every now and then but usually fizzle out after a few years. We'll see how long neovim stays around.
(And the MacVim native Mac UI is pretty nice imho.)
I'm really stoked about neovim. I hadn't really thought about it, but it'd be interesting to really go through all the substantial efforts to fork/clone/refactor vim and compare/contrast their primary goals and vision with neovim.
Might be fun to do some light reading on it tonight
I was really excited as well, until they decided to remove the encryption completely.
The nice thing about the encryption in vim was that it was a cross platform way for encrypting and decrypting plain text. I use it nearly everyday on my (work) windows pc, headless ubuntu server, macbook pro and nexus 5. And the only thing I have to do is open the file with vim.
That's a bummer for you, but does it really kill it completely? The way they are going it seems like they are making significant tradeoffs to remove legacy code in order to support modern features on modern systems. This should make it possible to be a true competitor in the GUI space to Sublime, but at the cost of ubiquity. I expect vim will continue to live on in most Linux distributions for the foreseeable future, even if neovim gets major traction amongst developers.
And personally I am fine using neovim on my dev box, and firing up vim on the server. Is that a non-starter for you? Do you really need automatic encryption on all your daily editing tasks on your dev machine? And if so, why are you not using full disk encryption?
Every few days I see something that reminds me I really need to learn how to start contributing to neovim (probably by writing tests in lua). I really can't wait until it is ready to use and I can try writing a plugin.
Though I always like to learn more about Vim, there are way too many commands in this list to call it a "Best of", and it seems that many of them are not actually that useful.
Don't let this list intimidate you, Vim allows you to learn at your own pace, I was mashing h,j,k, and l for years before I learned the beauty of grouping movements (e.g., 12j instead of j 12 times). I try to learn one new thing a week so I can commit it to muscle memory.
It seems like so much of power vim use is about jumping 3 characters ahead or 12 lines down.
Is this for real? Do you count the number of lines or characters before you move? Do you look at line numbers and do the arithmetic in your head? This can't be right, right?
> Do you count the number of lines or characters before you move?
I think most people use commands like f) (move to to the next ')' on the current line) more often than something like 12k (move twelve chars to the right), because, like you say, counting chars is slower than mashing 'k'.
People just use 12k because it's a simple example of how vim commands can be chained together. As a less-contrived example, you can do 2f) to move to the second ')' on the current line.
Personally I just estimate and correct. Usually I use numbers that are easy to type with the left hand so I can keep my right on the home row. If the place I'm moving to is 17 lines up, I'll likely get there with 15jjj. Even with relative line numbers turned on, that feels faster for me than stopping to look at the number. (Haven't timed it, but feeling fast keeps me in flow so that's my metric.)
Various semantic movements help a lot, too. But I never stress on hitting the target exactly, I'd rather get nearby without thinking than stop and think to get there in one command.
It's more about "semantic editing" than memorizing arcane keybinds. With Vim, you describe what you want to do with actions and motions. Motions move the cursor from a starting point to an end point and then actions do something with everything between the start and the end.
For example, if you want to delete 3 words, there is an action to delete (d) and a motion to move forward one word (w): 3dw (read (3) times, (d)elete (w)ord)
If you want to delete everything up to a closing bracket, there's a motion to move to the next occurrence of a character (t): dt)
(read (d)elete (t)o ')')
It becomes much more productive when you're thinking in terms of composing actions and motions to achieve a goal rather than memorizing situational key combos. The hardest part is getting over the hump of memorising the actions and motions.
Relative line numbers aren't even too important, given that there is a motion to jump to a line number. If you have a function that you can see starts at line 6 and ends at line 14 and I want to move it to the top of the file. You want to go to line 6 (6G), delete (d), go to line 14 (14G - thus applying the delete action to the motion of moving from line 6 to line 14) then go to line 1 (1G) and paste (P).
> For example, if you want to delete 3 words, there is an action to delete (d) and a motion to move forward one word (w): 3dw (read (3) times, (d)elete (w)ord)
I prefer to use d3w since it feels more like English. It's also more compatible with other combinations like ci" ('change inside quotes', e.g. to change a string), ca" ('change around quotes', e.g. to replace a string with a constant), or yt{ ('yank to brace').
% will bounce back/forth over matched pairs of (), [], {}. :/foo/z6 will move 6 lines after the line that matches "foo" (I know it's not eliminating counting). There are also word, sentence, and paragraph movement available.
I "bookmark" important lines with named markers "ma", "mb", etc for "a" and "b" markers respectively, available as 'a, 'b.
Not to mention cscope or ctags for finding function declarations, various call chains, etc., etc.
I use relative line numbers so I don't have to count, vim tells me how many lines are between my current cursor position and wherever I need to jump to.
Hah, I didn't think of that! Just before reading this comment I was working along in the editor, furiously pressing j/k. I'll put this to use immediately.
Yikes! The continually changing numbers drives me crazy. Thanks for the tip, but I think I'll stick with just using ":13" to go to line #13... I guess there is some benefit if you do a lot of yanking/cutting based on lines, rather than some magic matching or such. But for now, relative line numbers is not for me.
n jump to the next occurrence of the last search
N " " " previous " " " " " "
* jump to the next occurrence of the word under cursor
# " " " previous " " " " " "
Yes! Also, ^R^W (ctrl-r, ctrl-w) when you're at the : prompt will drop in the current word under the cursor. Which is also quite useful in keybindings.
Thanks. That's a great tip. I've always yanked the word that I wanted and then used Ctrl-R" to paste it on Vim's command line. This is much better.
I'm now off to read "cmdline.txt" (:help Command-line).
BTW, I just accidentally closed my browser tab (latest version of Firefox) by hitting Ctrl-W when I wanted to delete the previous word in this textbox. That used to drive me mad but when Firefox restored the tab, it also restored the text I'd typed. :)
or alternatively try the easymotion plugin[1] which you press <leader><leader>j (or whatever you map it to) and then it will highlight each potential line with a letter that you press to go to that line. j is one of the worst examples, it's nice if you are doing a dw so you don't have to count the words, you would just do d<leader><leader><motion> and it will highlight to the potential places.
I don't know, if this were a "Top 10 vim tips, number 6 blew my mind" style article I feel I'd engage with it more. Also, show only one tip at a time with pagination so I can learn one thing at a time.
I don't know what the other guy means by weird, but I mean the extremely high your-brain-has-to-operate-like-a-combined-parser-and-compiler to make any sense of that kind of thing. You're telling me you're not dulled into a stupor by trying to read that?
It's nice to not "read more after the jump" or "below the fold", no over-pagination, no 100% width 400px deep semi-relevant banner image, no pull quotes in 30px ultra-bold fonts floated over to the sides, no "you may also be interested in" and no asinine comments, .. oh, wait!
I disagree. This is way to much information for me to digest. I think a happy medium is nice. Enough information on the screen to get the point across but not too little that I have to click everything to find out what I need.
Of course I'm exaggerating, and I agree this page isn't particularly friendly but nor is it intended to be, its a reference to be searched rather than a piece of prose to be read.
A lot of pages I find frustrating are often trying to spin a narrative around what amounts to reference material, or vice-versa & results are often framed with the tropes I mentioned above.
Wow, thanks for the tip, any ideas on what it does?
A lot of these seem to be learn to use regular expressions and not really vim related other than vim supports regular expressions. I.E. the 4 or 5 different ways to find an exactly 4 digit number that mostly seem to boil down to '/' does search by regular expressions and here is a regular expression that finds 4 digit numbers.
Also YouCompleteMe[0], which uses Omnisharp for C# and Jedi for Python. It has recently been refactored into a standalone server that talks to the editor plugin, so we may see this in other editors.
I've been using vim for the last 2 years, and I love HN for posts like these, with all a-ha's in one page. Considerably reduces time necessary to become a vi master.
These sort of tips are only useful in highly specific cases. It's probably not worth learning them off by heart because of how infrequently you'll end up using them. BUT, understanding how the author(s) came up with these is incredibly powerful. The combinatorial explosion of the composition of Vim features means that it's practically impossible to learn all of the commands.
That said, it's really beneficial to learn how to form these commands yourself. For instance, if you know regexes, a good chunk of the commands presented would be relatively easy to come up with yourself. Is it worth learning regexes, Vim shortcuts (basically a lot of arcane things)? Maybe, maybe not. If you spend (or plan on spending) a huge amount of time manipulating text files it's probably worthwhile. For me at least, it's much more satisfying to do most text manipulations (e.g. remove trailing whitespace) by running a concise command, than doing it manually.
For what it's worth, it's even fun to sit and think of how you can avoid doing some manual task. Vim shortcuts + regexes are a really good way of avoiding silly work.
At a guess: the old-fashioned Unix way of composing mail and Usenet messages is to have your client call your editor. Rot13 was (is?) common in Usenet discussions of fiction to avoid posting spoilers where anyone can accidentally read them. It's not something you would use when editing source code.
You know when you read someone's comment and then your immediate thought is "I'm way too old to appreciate this"? I read your comment and thought the exact reverse. I'm way too young to appreciate this.
nmh is a mail client that is decomposed into a bunch of shell utilities, storing state and messages in files. It's a bit awkward trying to use it directly, but easy to wrap things you do commonly in aliases/functions. Editing of messages, of course, takes place in your $EDITOR, but listing of messages, selecting of messages, &c, doesn't leave your shell like it does with mutt (so you can use the pieces as part of arbitrary pipelines, as is good and proper).
Just a nitpick, but applying a command to the whole file can be done faster with ggg?G
That also has the benefit of working with plain vi, since vi doesn't support visual mode.
I didn't know about the rot13 command. I probably won't ever use it, but I think it's fun that it exists.
I love Vim but never use it. 99% of the time I'm editing code in an IDE that knows about the language semanticly and knows how to refactor (extract/move/rename) code. It would be incredible if Vim/Neovim had a plugin that could do the same refactorings as IntelliJ.
At the moment the ease and frictionlessness of refactoring like this (instead of manually moving text objects around) beats Vim's productivity gains. It's a shame because I still often think in terms like "ci(" when using an IDE.
I've tried Vim emulators in IDEs (not recently, mind) but they're not the same.
Anyone have any suggestions to get the best of both worlds?
I'm a relatively happy user of Vim emulators in IDEs (mostly in VS / IntelliJ / Eclipse); e.g. I might do a cw / ciw / ct[first letter of next word in variable name] and then hit the IDE's shortcut for rename refactoring. Simple macros for tedious repetitive tasks. For this, I find emulators sufficient, a kind of "best of both worlds".
I suspect my usage of Vim itself is fairly basic, making this workable. What issues did you find with this approach?
I started using vim only recently, and when I was running through vimtutor, I was telling myself how I'd never be able to remember or understand what is w, W, B, E, {, dib, ci(, ma{{{yy`a"bddp (maybe there's a better one than this) or :%s/a/b/g.
After only a month or so of usage, I've come to use commands and sequences like this by heart. And when I read useful tips or watch screencasts, I'm just remembered how I've barely even scratched the surface of productivity with vim.
That's why I don't fear I won't be able to remember more and more new, complex commands. I think it will all come naturally, like the first ones I learned. The same should happen not only with me, but with you or anyone else who is dreadful of remembering increasingly complex workflows of commands with vim.
One very useful advice when it comes to 'what to memorize' is trying to always watch yourself using vim. If you happen to do something repetitive, ask yourself: is there a better way to do it? How to automate it? And then, commit this new tip to memory.
This way, you actually only memorize what is directly useful.
This tip has served me very well.
Sort of let's me wonder, why anybody would want to learn all those. I use vim regularly, but to be honest, for 90% of tasks i would be just as efficient with pico or mcedit.
I guess i am using vim only because it is most often available on 3rd party systems and because of the occasional need for those last 10%.
And to be honest, i used to use vim on the desktop for some time, but now we have this variety of options.. from fast loading textadept, gedit, sublime text3 to full-blown IntelliJ.. Why vim? Because it's "cool"? Feels more like ancient and antiquated.
Nice list though, it's bookmarked for those 10%! :)
Hardly anybody would want to learn all of the features ofcourse. There are advantages of using vim which other editors can't compete with (imho):
- A just booted VM with with no window manager installed. You have very few choices, but can always count on vi being there.
- Abstraction: One builds up the knowledge of different things over a period of time. For exaxmple, once you learn 'w' is next word, it can be combined with the new knowledge of 'd' for delete quite intuitively. Not saying other editors don't have that.
- Each popular editor I know of has a VI mode built in (or easily available). So, being comfortable with vi means being able to use any of the mainstream editors with vi mode, but not the other way around.
It's useful to see how others apply vim's grammar in interesting ways. To me, it's like seeing a new design pattern. Not necessarily immediately useful, but a maybe a new way to think about something I may not already know.
That's the way I approach some lists like this one. Specific examples can help one to in turn better learn and generalize certain abilities/behaviours.
I'll also add: So, one person puts up a long-ish page of examples. Is there anything inherently wrong with this? Presumably, it's useful to them and perhaps to some others. Doesn't that suffice -- it's the Internet!
Not every page needs to be carefully curated for global karma-whoring.
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.
http://www.emacswiki.org/emacs/Evil
Seriously, to me it solved all my issues with Vim. Now I have several processes attached to my "Evil", heaps of plugins installed, yet everything blazing fast. And the configuring in elisp started as a little awkward, but now it feels so much more sensible then vim-script (especially knowing that development on Emacs started ding the 70s).
With Evil I can say that --for me-- the Vim/Emacs fight is over:
Emacs now has a great editor...
...and Vim a proper "operating system".
:)