This article is well written, but it has nothing to do with mastering Vim. It goes no further than running "vimtutor" at the command line. It has all the same tips and shortcuts as any other vanilla Vim tutorial. This is a common problem among Vim articles and tutorials. Authors title them as if it will give you Vim mastery, but instead it only offers the basics.
Mastering Vim means going beyond vanilla movements and learning all of Vim's nasty warts to replace good GUI features. It means learning the wonky, dead Vimscript language. It means knowing how to use the arcane arglist. It means knowing how to go into insert-normal mode, and when to use the expression register. It means knowing everything about very magic search, and why default search is poorly designed. These are all randomly chosen examples, because mastering Vim involves mentally juggling a very large playbook of oddball features to complete editing tasks.
The main resources to help you master Vim are the book "Practical Vim" by Drew Neil, and if you're ever in the unfortunate position of needing to write or edit a Vim plugin, "Learn Vimscript the Hard Way" is invaluable http://learnvimscriptthehardway.stevelosh.com/
For one thing, not all of the things you said must be mastered, vim is plenty big enough to support various ways of working. E.g. I never use the arglist.
For another, from a pedagogical perspective, there's different levels of "mastery", and there's nothing worse we can do to scare off people trying to learn a new editor than to tell them "oh, no, to be considered a real master you need to put in months of learning".
This is hardly a primer. If somebody is using the motions and actions described in the article they may not be a complete wizard in obscure vim features, but they are certainly far beyond being merely "primed" to use vim. I've been an avid vim proponent for years and I still picked up new things from this article.
My issue with getting better at vim is that I've gotten to the point where I'm comfortable moving around text, copying/pasting, and everything I would normally do with a mouse. I know vim is so much more than that, but it's one of those things where "you don't know what you don't know" and because of that, I don't have the incentive to continue learning. Hopefully this post will inspire me to incrementally advance my vim usage.
Here's the secret to getting good at vim, at least in the beginning (and at least for me).
Step 1: Start using it in your work.
Step 2: Find out something that bothers you. E.g., something you miss from another editor, or some kind of movement that you make a lot and would really love to automate.
Step 2': Very important for Step 2 - you have to really hate doing anything repetitive or annoying. With time you'll get a feel for what is easy to find a solution for.
Step 3: Figure out how to solve that specific problem.
Later on, you may do what other people say and look around for videos of other people using vim, look at plugins, etc. I only started doing that after I got much "better" at vim.
Just a quick example: I was editing a lot of css files, which always have lines like:
.some-rule {
sometext: 234px;
}
And every time, I'd want to change the number (e.g. change 234px to 200px).
If I used the "standard" vim toolset, I could just jump to the number 2, then do "change word", but then I'd have to retype the "px" every single time, and this annoyed me. Now, there are plenty of ways of dealing with this problem, but I knew about something called text objects, and decided to investigate the idea further, and soon found a plugin that makes numbers a text object.
The end result is that I now have mappings to "jump to the first number in the line" and to "change a number", so my flow is much simpler.
This is a small annoyance thing, but let me investigate the whole topic of text objects, creating custom mappings, etc. And, it solved an actual problem I had.
Step 4 (for me) was realizing that all of these plugins to solve small individual problems were just a bunch of cruft. Especially when you use these plugins, mapings, or remappings (I did that a lot) to hide from learning all of the vanilla movements. So, I still use plugins, but I use them to solve things that I cannot myself solve. Or deal with major vim deficiencies that I just don't want to mess with. And focus my attention on grokking 'help' to learn more abscure movements.
Oh, and mappings/macros are awesome in cases were you want solve specific problems in less moves. I use macros to test out my ideas. I sometimes then make them a mapping. That isn't often, but when I do that, it's because they are general and needed enough.
Capital letters and numbers are global, lowercase is buffer local. There are also dynamic marks that vim sets which you can use instead of manually navigating or setting marks. For example, g'. will go to the position of the last change. You can use :help marks to get a lot more info.
Slightly tangential, I also found "Your problem with Vim is that you don't grok Vi" a good source of things to learn from. While it starts off sounding like a rant, it isn't - I think it actually manages to convey a fair bit of the philosophy :)
Opening a new buffer. Figured I'd try :new, and wound up getting good at splits. Still don't know how to just open up a new, blank buffer in the window I'm in without specifying a filename to :e.
I use them all the time (I've switched them on by default in .vimrc) while editing C++ code. Extremely, extremely helpful to get the structure of a file at a glance. For example, if a 400-line file has about 10 functions in it, you can fold all "zM" and instantly you see only the function signatures, while the bodies are folded.
How to enable it: use "set foldmethod=syntax" (with C++) or "set foldmethod=indent" (with JS, where "syntax" doesn't work for me). Also, I use "set foldminlines=0" so that 1-line paragraphs get closed as well (it looks more consistent).
How to use it: close all folds "zM" (I remember it because the M is shaped like it's all folded on itself). Open all folds "zR". Open one fold "zo", close one fold "zc". Open one fold recursively "zO", close one fold recursively "zC".
By the way, I almost never use manual folds, so "zf" is almost useless to me.
I use folds for one specific thing: I have a general "notes" file for home and for work, which is a big outline where I put anything I'm thinking about or working on. I usually don't delete stuff, so the file grows over time. I make a fold for each top-level item (~project or subproject) and sometimes nested folds if things get too big. I always use fdm=marker. The automatic fold methods are too confusing.
Everyone uses tag files, in some sense, when they use :help :)
I don't use folds that often, but when I do they are be extremely helpful. When you run across that block of code that's way longer than it should be, and need to collapse it so you can see the context around it, folds can be very useful. Also for taking care of long comment blocks.
So while I agree with you in that they aren't a part of my typical workflow, they are a piece of vim that I'm glad I familiarized myself with.
I couldn't live without folds. Whether I'm in C++, Java, Go, Ruby, or a custom ASCII report I've written, I use them extensively. I add fold tags around every method/function implementation, and sometimes an additional one around around groups of them (e.g., classes). I generally set foldlevel to 0, so most files I enter have a few intro lines and then N folds, so that even large (1000+ lines) source files fit into a single page or two. I almost never use searches or tags to find declarations, since I can usually navigate to them directly with a single keystroke.
FWIW, I map <Space> to za, so that I can unfold/refold quickly. I also map - to zx to quickly fold up a file I may have drilled some holes in.
I use them for learning a library or framework. I'll fold all of the functions, methods, etc. in a file and and then unfold to dig deeper. I work on a 13" mba so it helps with the lack of vertical screenspace.
I still don't fully understand how folds work (e.g., how can I get them in my JavaScript files by default?), and thus I find them difficult to work with, but when I can get them to work, I'm very glad of them. They make navigating round a large file much easier.
I use them. They don't help as much with new development, but when editing a large pre-existing code base it makes perusing the contents of a file much easier. It's like getting a table of contents for free if your code is cleanly organized.
Being able to move about is the first step. The second is to see that you can combine actions with motions. There are many more, of course - but IMHO, crossing these two steps takes you past the tipping point.
For example - '%' matches parentheses and braces. So if you want to delete a block of code, you could go to the opening (or closing) brace, and do "d%". If you wanted to indent only that block of code, you'd do "=%". In this context, ":help motion.txt" makes for a good read.
Apart from this, I'd also recommend listing down things about your current workflow that you find irritating, and trying to find solutions for them in vim.
For instance - I wanted to be able to browse through cscope matches in a regular vim buffer than the ridiculous less-like interface that's the default. I found quickfix, which solved my problem neatly. I then wanted to open each match in a vertical split, rather than in the same window - I ended up writing a little bit of vimscript and a keybinding for this.
Sometimes, when going through a gazillion cscope matches, I find it convenient to hide stuff that isn't relevant - I use (manual) folds for this purpose.
advice: put just a bit more boring memorization type time into honing your discovery ability; ie hit the :h a bit, find some tutorials you like, pick up the "practical vim" book, print out a vim cheat sheet. not too much; just enough so you have somewhere to go when you have a question.
then, code in vim. at every pain point ask "is there some faster/easier way to do this?" sometimes you'll find something that seems great, then never use it again. other times, you'll relieve a recurring pain point and at the same time incorporate expanded facility with vim. after awhile, you'll pretty naturally start messing with vimscript as well.
in other words, i think videos and tutorials of "look at how powerful vim is in this situation!" can only go so far, at least until you've really expanded your horizons through practical use and need.
edit: the earlier advice in responses to you (some of which i basically just repeated) is good too. mine could be distilled into a sentence: "learn vim by coding in it, but allowing time for 'how could i do this better?'" on the one hand, just do your normal work. on the other hand, don't stay satisfied with being "good enough" at vim to do your normal work. that's where the learning curve is, and after you do that artificial thing (overdoing "can i make this easier?") it quickly becomes natural.
The thing I've found to be really effective at learning "what you don't know"is pairing with other more experienced vim users. You'll see some wizardry occur and you can ask them how they did it. I consider myself an experienced vim user and I still learn new tricks when pairing with other people. Obviously not everyone knows vim users to pair with, but you may be able to find people at meetups.
"My issue with getting better at vim is that I've gotten to the point where I'm comfortable moving around text, copying/pasting, and everything I would normally do with a mouse."
exactly why I use Vim this way. On DEC VT-100 terminals this was the only way you could work and I must say I sometimes cheat and add the necessary bash commands to make it work on my console.
I consider myself at least an intermediate user of Vim, and I'm glad that you mentioned the "f" motion (along with its cousins "t" and ";"). I don't think these keys get enough exposure among beginner Vim users (they aren't mentioned in vimtutor), but they allow you to quickly and efficiently move across files and do things like "ct(" (change text up to first left parentheses), which is super useful for changing function names.
The commands you mentioned along with "ci'", "ci[", and "ciW" to replace all text between delimiters have been some of my favorite to use. It really annoys me when my terminal's vi-mode doesn't support "ci" (I think it's vim-only).
By the way, in your specific example, "ct(" is not necessarily the most efficient, because most of the time a function name will be a nice alphanumeric string; hence you can use "ciw" which will work anywhere in the string, not only at the beginning.
The thing that always frustrated me about Vim (and command-line apps in general) is that it punishes you for being a GUI power user. The more mastery you have of conventional GUI keyboard shortcuts to highlight, jump words, copy/paste, etc., the more often you will reflexively hit them and do the wrong thing while trying to use Vim. You have to unlearn a lot of perfectly good skills before you can really master Vim, and that's frustrating.
Of course it's not Vim's fault that the standards established by vi were not taken up by the early GUI systems, but I wish there was a better way to deal with this problem than a figurative grizzled old console cowboy going "suck it up, n00b, it builds character." I'm aware that people have made command sets that make Vim and the *nix console in general more GUI-standards-friendly, but these are never presented to actual CLI newbies, so by the time you're aware of them you've done half the work already...
I have the opposite problem. When I'm writing stuff in MS Word at work, I'll often see a ":w" appear in the text when I automatically try to save the file Vim-style.
Cream[0] is a configuration for Vim that makes it work in a way more familiar to people used to Word and other traditional Windows GUI programs.
Way more useful (for me anyway) is mapping Capslock to ESC. It works with any vi anywhere as long as you are using your main machine to connect. Also with inoremap don't you have to wait for the letter j to show up until you type your next character? That would drive me crazy.
Edit now that I have actually looked at the article: Yes, you can map it to Control but for me it's an awkward place to put a modifier. What if you want to do Ctrl-A? Ctrl-C? At least the way I type, I'm better off using the one in the corner.
This works great on my Linux machine. On the Mac though I hate that all Mac apps use Command for well, all command-key combinations instead of Ctrl, so I map the Caps-lock to Command instead, but while Karabiner can do the dual "Esc on tap plus other on hold" for Ctrl, Shift and Option keys, it cannot frustratingly do it for the Command key. ITerm can switch caps-lock back to Ctrl, but then I lose the Esc double function. It's maddening.
I'd actually like to map Caps-Lock to ESC as well, but I'd prefer to make it vim-specific rather than system-specific, and there's no way to do that :(.
I prefer to avoid remappings so that I can use vim at any machine without having to figure things out, so my preference for escape is Ctrl-[. It takes a bit of getting used to but once you get it, left hand never has to reach up anymore.
It's definitely more efficient. I've had it mapped that way for years, and after a short time it basically became a single keystroke.
The efficiency doesn't come from the fact that it's not as far to reach. The efficiency comes from the fact that you don't have to find home row with your left hand again and can continue your command sequence immediately.
Better yet, ^[ is actually ESC in vi/vim, and works without a config change. I started using this last year and haven't looked back. ^C works well, but I recall it having some limitations in certain environments (though for the life of me I can't recall what they were).
In any case, I prefer ^[ to ^C, and hopefully you will too!
One of the best things I've done, though I personally use 'jf', since they've both got little nubs on the keys, and I occasionally have to spell "Dijkstra".
From the article: "Arguably the most brilliant thing about vim is that as you use it you begin to think in it."
Bill Joy, regarding vi: "It's like one of those pinatas--things that have candy inside but has layer after layer of paper mache on top. It doesn't really have a unified concept. I think if I were going to go back--I wouldn't go back, but start over again."
Hunter S. Thompson, on an unrelated topic: "That was the fatal flaw [...] the desperate assumption that somebody--or at least some force--is tending the Light at the end of the tunnel."
I think vim is a useful tool. It's available on most systems and is powerful. But trying to grok it and appreciate its UI isn't really something I want to do.
While a tweaked configuration can be a great productivity boost, it has a major drawback. My main reason for using vim is its ubiquitousness. Whenever I need to ssh into a box to check something out, I can trust that it's there. However, I cannot trust that its configuration has been tweaked like I expect. Hence, I stay away from getting used to non-standard key mappings.
Checking something out on some server does not require remapped keys or commands: you generally just browse some file and fix a couple of things. Tweaked configuration for more involved tasks is fine, to me.
I think this follows the 90/10 rule. Most of my work is on my own machine. Occasionally I will be on a server and attempt to use some configuration from my personal .vimrc but instead have to fall back to slightly slower methods.
The time lost in that 10% is totally worth the cost of the time saved in the 90%.
And since everyone uses their text editors differently, it's not practical to move any one individual's personal configuration choice into vim core.
I have my interns setup Vim on their first day, and it's usually their editor of choice by the end of the summer. Apparently it gives them mad credit among their peers at school too.
Great tutorial. About 20 years ago, I was a Level 4 user (by the article's definition), but that knowledge faded with disuse. When I switched back to a Linux/UNIX machine about a decade ago, I started using vim again (well, I started using vi again, but it was vim), and remembered a lot of Level 1 and 2 stuff, and could recall being able to do more, but never had the motivation to crawl through the man page to force myself to recall how I did more.
This article is so logically laid out I think anyone could get to at least Level 3 with the article and a few hours diligent practice. Level 4 would then beckon....
When I became a serious sed - and then ed - user, I became a much better (faster, more productive) vi/vim user when I didn't need to be in visual mode all the time.
from config: "I remap it to Ctrl at an operating system level. This way my left pinky can simply slide to the left by one key to execute Ctrl-whatever."
Been a while since I used emacs, ctrl-everything is an emacs idiom [0] and a pinky killer. I guess the best bit is it's configurable. Really like this tute Daniel, found a nice add for my .vimrc already.
Learning vim is easy, I've done it a thousand times! (As Mark Twain might say)
This time around I've been keeping a list of the stuff I miss from my usual workflow. Here's two of the most maddening:
1. Searching for literal text. Is there a way to avoid having to manually escape special characters?
2. Maintaining cursor position when scrolling. Maybe I want to go look at another part of the file and come back. How can I scroll without it moving my cursor?
> 1. Searching for literal text. Is there a way to avoid having to manually escape special characters?
Put "set nomagic" in your .vimrc. This makes e.g. "." match a literal period/full-stop rather than any character. To get the special behaviour, escape the character: e.g., in nomagic mode, "\." matches any single character.
If you only want this behaviour occasionally, putting "\M" at the start of your search will invoke it for that search only: e.g. "/\Mfull.stops.only" will match "full.stops.only" but not "full-stops:only".
Even in nomagic mode, a few characters are treated specially, e.g. "$" for end of line. To suppress even these, start your search "\V": e.g., "/\V$1000". N.B., you can't make this behaviour permanent in your .vimrc: you can only invoke it search by search.
If you want the full gory details for all of the above, try ":help pattern" in Vim.
1. For the mnemonic, "\v" turns on "very magic" where all possibly special characters will have their special meaning without prefixing them with "\". Now, "\V" is just the opposite of "very magic", which is "very not magic", i.e. disable all special characters.
2) is generally accomplished with marks. Press m followed by a letter to set a mark where you are, go down to wherever you want, and then you can pop back by pressing ` (backtick) followed by the letter you set for the first mark.
If you want to go back and forth, you can set two marks.
Pressing `` (backtick twice) will jump you back to the place of your last edit -- unless you've explicitly set another mark in the meantime, in which case it'll send you there instead.
Assuming the stack grows up, ctrl+o moves you down the stack and ctrl-i moves you back up the stack. Pushing occurs on certain evens like searching and using marks. iirc, popping occurs when you push something onto the jump stack when you aren't at the top and the old <next> (ctrl-i) is replaced by the new current location.
Thanks for this tutorial. I'm at Level 1 having switched from an IDE (PyCharm) and I find this helpful. Any reason why you use Pathogen vs Vundle for managing plugins? Does it even matter?
You're doing yourself a disservice. Intellij (PyCharm) has a vi plugin. Whatever extra stuff you give up from regular Vim, you gain an order of magnitude of productivity using a development environment that is "smart". Think about what PyCharm does for you and what Vim doesn't.
Vi(m) is a model, not an implementation. I wish people would stop handicapping themselves with very bad implementations. Intellij, Visual Studio (Resharper) understands the languages your working in. Let the machine do what it does best and aid you in the language while you concentrate on domain.
In that spirit, I find it hilarious that the entire industry proudly releases products weekly that do things like re-order laundry detergent at the press of a button or games that require the player to do nothing more than swipe their finger this way or that. On the other hand then there is this long raging religious war over the tools used to build these products where some claim the end all be all is this text only, esoteric, super high learning curve tool. Sure it's superpowerful once mastered, but as in so many other areas, the argument that you just made seems to carry the day: let the machine do the work.
Text-interfaces are the most direct and flexible way to get the machine to do work. When you're stuck to a consumer-friendly GUI, you can only command the computer the way the product has been designed to command the computer. You learn how to use a product rather than how to teach the computer.
That said, of course I use a web browser for 99% of my Internet actions. But being able to Alt-Tab into the terminal and run wget to quickly pull down a list of files may feel like 1970s-era, but it's still a powerful technique today, and for as long as users need to do things beyond what designers intended them to.
Respectfully, I propose you are limiting yourself when using left-to-right text-interfaces. I think consumer-friendly may be a bit unfair as well. I'm currently learning sign language and in parallel programming a Leap Motion interface so as to bypass one-dimension (a line of symbols) and two-dimensions (a gui on a plane) and more easily encapsulate concepts (words) by states of motion in three dimensions.
Text-interfaces work well because they restrict input to precise parameters, however as interfaces become "smarter" and are able to capture the meaning of imprecise interfaces such as hand gestures and interpret them precisely without requiring the user to deliver them with robotic precision, interfaces will become more expressive, we will be able to work more naturally in the domain in which we think, which is, these physical three dimensions.
If you've ever watched a mathematics professor write on the chalk board you'll know what I mean. So expressive. So much conveyed with so few markings. And yet, very sloppy. But still. Reading it off the board, those symbols just feel so much better in your head than any words would.
No, vim is an editor, not a model (whatever that means) and definitely not an IDE. These are very different things.
I use vim to edit all sorts of text (including for instance this text box, using It'sAllText[1] ). Why would I use an IDE for that ? That'd be silly now, wouldn't it ? ...and at least for me, once I got used to using vim, I didn't see how the IDE could better '...aid you in the launguage ...' than vim itself.
I think PyCharm is awesome, but the reason I switched to vim is because I have to code on a remote machine especially when I don't have a Vagrant synced folder setup. I'd love to try vi key bindings on PyCharm, though!
Depends on your needs, Pathogen only manages your plugins, but Vundle, will checkout the plugin, install it, and you can update all your plugins from inside vim.
Is there a way to navigate words taking camel case into consideration? helloWorld should be treated as two words when I want to delete or move, at least sometimes when I want to edit.
I am sure there is a 'normal' way to do it, but look into easy motion. I use space in normal mode as a shortcut to go to any word in the line and that includes camel case movement.
Vim is a regular expression system hooked to a 1970s user interface. If you need to apply regular expressions to text files, vim is useful. I used vi to write code for years, but that was decades ago. There's been some progress since the 1970s.
I barely use the regexps. There are 2 things that vi/vim are quite good at that are very relevant today. I don't know of any alternative that is as good.
First, efficiency of bandwidth over an ssh connection. You might think, "Oh but there is tons of bandwidth on the internet today". However, I actually use vim to pair program with people in the UK while I'm in Japan. Vi commands can easily deal with variable latency and still give good performance because you are almost always in command mode. Instead of arrowing down to some character, I simply tell the editor where I want it to go using a language with a grammar. I have very happily coded all day with 300+ ms latency in Vim. For me this is a killer feature that is painful with any other input system. (vi is even better at this because it reduces the number of repaints to a bare minimum).
The second feature is very much related to the first - the use of a grammar for describing what you want the editor to do. With most editors, you press a key and it does something small and specific. With vi/vim you describe things that you want the editor to do with sentences.
This is a great example of the difference between ease of use and ease of learning. vi/vim is very difficult to learn well (or at least it takes a lot of time and practice). But it is arguably much easier to use once you have that learning. It's like the difference between "Pick up glass. Drink beer." and "Move hand. Move hand. Move hand. Grab glass. Lift glass. Move hand. Move hand. Move hand. Tilt glass. Drink beer".
Sure, it's not for everyone, but it's clearly not reasonable to say that the state of the art has improved in these respects. I can think of no other editor that even attempts to solve these problems. If you know of some, I'd be happy to learn of them.
I by no means agree with the guy you're replying to, but I don't think your vocalized example is fair. With vim, your state is in the "sentence" you've written. With a typical editor your selection is in the state of your editor, primarily its selections. It's more like "Do this here." vs. "Look here. Do this."
One thing I used to do is visit http://www.vimgolf.com/ and compete with the best solutions there. Aside from a higher usage of meta characters (which is a modal vs. quasimodal thing, rather than a sentence vs. select thing), my editor of choice (Sublime Text) rarely lost out.
There is the caveat that some things that are great for golfing are relatively useless elsewhere (eg. numeric modifiers) and vice-versa (command panel: trim trailing spaces). I miss the later in vim much more than I miss the former in typical editors... although I still hacked it into Sublime anyway.
We actually have several licenses of Sublime kicking around at work because everybody moved over to Vim. I know several people who are really fond of Sublime, but lack of a text mode put it at a bit of an evolutionary disadvantage in our shop since we do a lot of remote pair programming over SSH. It's a bit of a shame since we are almost a monoculture now (one guy still uses Emacs and 2 are vim/sublime bilingual -- every one else is on vim pretty much exclusively). I think it's nice to have some diversity to keep people thinking of the possibilities. I'm in the process of moving over to Evil mode in Emacs pretty much for that reason.
Probably my example was a bit poor. I wasn't trying necessarily make the argument that Vim is more keystroke efficient than other editors. I used Emacs for 20 years before I switched to Vim and I was quite efficient with it. I was more trying to convey the idea that the way of thinking was different. Instead of concentrating on the immediate motion of the cursor, I'm concentrating on the structure of the document.
Lately I've been thinking it would be nice if someone were to think a bit more about extending the state of the art in modal editors. Vim was a nice extension of vi, but the grammar is still pretty crufty in a lot of places. It would be cool to rethink it from scratch, I think.
> I was more trying to convey the idea that the way of thinking was different. Instead of concentrating on the immediate motion of the cursor, I'm concentrating on the structure of the document.
In what way does the multiple selection model not concentrate equally on the structure of the document? It's true that vim has a larger vocabulary than a typical editor, but its grammar is actually weaker. For example, I know of no way to combine two arbitrary motions.
Consider the case where you want to delete all strings containing the word die, where the string grammar is non-trivial. In a selection-based language you can
* select-all-"die", manually checking that they're inside strings
* select-enclosing-block
* delete
If one had a language-aware string token finder (and, frankly, a token-aware editor would be amazing - maybe I should edit Sublime to do that...), one could even
* select-all-string-tokens
* select-all-"die" inside selection
* select-enclosing-block
* delete
This is a very structural approach. I don't know a neat way of doing this with vim. (I'd be happy to learn I'm wrong!) There are other examples, like where one wants to work on some collection of things in lockstep and vim's inability to hold state through selections between commands results in a difficult workflow. The multiple selection model remains semantically unperturbed.
I would very much be interested in a modal editor that doesn't just try to copy vim - working on multiple selections with a large vocabulary and syntax-awareness would be wonderful. I also find some things, like temporarily restricting actions to a subset of selections, needlessly hard in Sublime. There's a lot that can be done!
Multiple selection does seem to be quite a powerful feature. I've never actually used it myself, so I'm not completely clear on all the possible workflows, but it's something that I know the Sublime people I work with miss in vim.
Speaking of token aware editing, smalltalk had an AST aware "editor" called a "refactoring browser". It could even infer the type of a variable by running tests and seeing what type the variable held in the running code. This is where you can get some crazy utility happening with automatic refactoring. Unfortunately most languages these days are needlessly complicated to parse (ahem... ruby).
I am toying with the idea of writing an Evil like mode in Emacs that gives the utility of vim, but without some of the cruft from vi. I think Emacs is a good platform to do it in since it gives you a lot for free (especially a nice lisp interpreter to implement features in ;-) ). However, I have far too many things on the go as it stands :-(
To be clear, I it's not trimming trailing whitespace I miss; it's fuzzy, graphical command search of human-readable phrases. I'll never remember a shortcut for shuffling selections, but I'm more than happy to type "shuffle" and use my eyes.
"a regular expression system hooked to a 1970's user interface" + a whole lot of awesome plugins!
Incidentally, there is nothing inherently wrong with 1970's user interfaces. My car still has a steering wheel just like cars did in the 1970's. And there is a reason for that. Because it works really well.
That's just not what vim is... I don't even really know where to begin, you're just flat out wrong. I'd say you're confusing vim with something else, but I don't even know what else fits that description.
It is a true if disingenuously narrow-sighted description of the origins of vi as a visual interface to ex, a regex-based line-editor and descendant of ed. Even the ascetic ed, however, cannot be reduced to a "regular expression system." All the more is it untrue to claim that vi added nothing but a "user interface" to ex. (As if `dib` and `ct;` and `gqap` and `zf` and `gj` were so effortless in a line-editor!) That is to say nothing of the (admittedly clumsy) scriptability of vim.
Even if you agree with vim's approach to modal editing and object motions, there is plenty bad to be said about it in light of some of the tools we have available to us today. But humble origins do not always lead on to humble ends. There is no use in calling a book bad and giving as your reason that it was once pulp. It would be just as unhelpful to call the Lisps of today slow, and to use as your crutch the old adage that "LISP programmers know the value of everything and the cost of nothing."[1] As GP said, "There's been some progress since the 1970s."
He does have a point. Using vi derivatives does seem a tad spartan today, and I've personally never been a fan of vi, nor of emacs, but much of the community has this pseudo-elitist dichotomy set up around those two editor families.
I'm not really a fan of what passes as IDEs, either, but I generally am not attached to any particular editor and hop around them.
(The right answer to vi vs. emacs is, of course, Acme.)
There's nothing spartan about it. Vim has tons of plugins. Using it as a Javascript editor, I've got syntax highlighting, git integration, linting, code completion, and more.
I actually began using Acme a couple of months ago: it's kind of interesting how much I have accustomed to mouse-driven interaction and lack of syntax highlighting. Humans indeed are creatures of habit.
Mastering Vim means going beyond vanilla movements and learning all of Vim's nasty warts to replace good GUI features. It means learning the wonky, dead Vimscript language. It means knowing how to use the arcane arglist. It means knowing how to go into insert-normal mode, and when to use the expression register. It means knowing everything about very magic search, and why default search is poorly designed. These are all randomly chosen examples, because mastering Vim involves mentally juggling a very large playbook of oddball features to complete editing tasks.
The main resources to help you master Vim are the book "Practical Vim" by Drew Neil, and if you're ever in the unfortunate position of needing to write or edit a Vim plugin, "Learn Vimscript the Hard Way" is invaluable http://learnvimscriptthehardway.stevelosh.com/