VIM Pays Excellent Dividends: Learn it early, if you can(medium.com)
medium.com
VIM Pays Excellent Dividends: Learn it early, if you can
https://medium.com/@generativist/vim-pays-excellent-dividends-814241804984#.8wqyr9ae9
64 comments
If I could go back in time and change one thing about my computing, it'd be to learn proper ergonomics and posture from the beginning and avoid the pain that came later. I often have to type slower than I can to avoid pain. I realize now that all the frenzy to get the ideas out as quickly as possible probably gained me very little time in exchange for a lot of pain. These days, a tool that might increase my data entry speed by 5% doesn't even make it onto the radar because my primary concern is my health and getting rid of RSI. Speed is antithetical to that. Interestingly enough, whether going full speed as before or in a more controlled manner like now, my actual productivity is the same.
I've used vim and emacs. I can't claim to be an expert on either, but I am somewhat comfortable with vim and it can be convenient for any unix straight out of the box. But I found it to be fairly overrated even with all these claims of boost in productivity. Just use Sublime Text in this day and age and use the spare time you would've had to learn vim and do something more useful.
Usually when so many people are saying something, and one's reaction is "I don't get it, I guess I'm missing something", they are, in fact, missing something. You can't really know what vim does for you until you commit to it and actually use it. Then over time the usefulness gets greater as you learn more things.
If you expect everything to be completely apparent to you the first time you look at something, that says more about your approach than the value of the tool.
If you expect everything to be completely apparent to you the first time you look at something, that says more about your approach than the value of the tool.
Well no not really. I've used vim throughout college and still do use it on occasion. But I have found it to not be as important to programming as a lot of people claim. If vim is that much more superior than other editors, by all means. I have not found that to be the case at all.
I've always been wondering if there is some secret that I've been missing and that these VIM or Emacs gurus keep to themselves which makes them "more productive".
All these abstract claims in blog posts and on forum pages about productivity are completely worthless. Go watch a stream where you can actually see someone program. Maybe you'll pick something up that they do better/faster/more elegant than you. Other than that, the best advice is to ignore these kinds of topics.
All these abstract claims in blog posts and on forum pages about productivity are completely worthless. Go watch a stream where you can actually see someone program. Maybe you'll pick something up that they do better/faster/more elegant than you. Other than that, the best advice is to ignore these kinds of topics.
I don't know about being more productive but I use commands like 3cwfoo<esc> to replace the next three words with foo. Or 2cf,foo<esc> to replace everything including the second comma on the current line. Or some : command. I no longer even consciously think about such things as how vi works is something I know in my fingers. Originally I learned such things only after repeating some command multiple times, thinking there has to be a better way, and then learning the more powerful commands. The core set of vi commands is quite regular and once you learn something it can be applied in other situations.
If I am working with another expert vi user it is very easy to give him precise instructions - I can just say things like replace the second foo with bar on every line starting with a space and he'd know to type the correct : incantation.
The key is to pay attention to your inner voice saying "there has to be a better way" and doing something about it! Bottom line: learn to know how to use your everyday tools well.
If I am working with another expert vi user it is very easy to give him precise instructions - I can just say things like replace the second foo with bar on every line starting with a space and he'd know to type the correct : incantation.
The key is to pay attention to your inner voice saying "there has to be a better way" and doing something about it! Bottom line: learn to know how to use your everyday tools well.
I also was rather sceptical wrt Vim at first; the only reason I ever started using it was that I needed a text editor that compiled for ARM architectures (I wanted to use it in a chroot on my chromebook). After a couple of hours the distrust got to "hm, this might not be too bad". After a couple of days I switched my ZSH to Vim bindings. Now I even use pentadactyl/qutebrowser for browsing the web.
The whole "Vim gives me amazing productivity" thing seems to be a personality trait: People telling you this are much more positive wrt tooling than I am. My basic gist is more like "why the hell can't I do X with this tool". I only started recognizing Vim's worth after getting more and more frustrated at other tools because they seemed to slow me down. Funny enough, I had the exact same experience a couple of years earlier after I got reasonably accustomed with Linux and Bash/ZSH. Learning them was more or less "meh", but coming back to Windows is a nightmare for me now. You have to do everything via the mouse, and the terminal seems almost unusable for me - it's not that I am amazed at how great my tools are (which, to be fair, they actually are), but I get very angry at any tool that doesn't at least do a decent job.
Luckily for me, this effect only seems to affect my experience with tools. I still can get very excited about APIs and programming paradigms :-)
The whole "Vim gives me amazing productivity" thing seems to be a personality trait: People telling you this are much more positive wrt tooling than I am. My basic gist is more like "why the hell can't I do X with this tool". I only started recognizing Vim's worth after getting more and more frustrated at other tools because they seemed to slow me down. Funny enough, I had the exact same experience a couple of years earlier after I got reasonably accustomed with Linux and Bash/ZSH. Learning them was more or less "meh", but coming back to Windows is a nightmare for me now. You have to do everything via the mouse, and the terminal seems almost unusable for me - it's not that I am amazed at how great my tools are (which, to be fair, they actually are), but I get very angry at any tool that doesn't at least do a decent job.
Luckily for me, this effect only seems to affect my experience with tools. I still can get very excited about APIs and programming paradigms :-)
I've been thinking about this lately, and whether my preference for modal editors is a historical accident, an adaptation to the limited resources available when I was an undergrad, or whether there's more to it. I think there's more to it. What separates vim and emacs from editors with a more forgiving learning curve is that they embrace a separate language for editing that's distinct from text entry.
That's not to say that other editors lack a meta-language. Even Notepad has Control-this and Meta-that. But vim and emacs (and my new favorite, kakoune) are all about using the meta language to manipulate text as much as possible, and only doing text entry when text entry is truly called for. Subjectively, I feel more productive using one of these, and completely hamstrung by IDEs, even when they supposedly support vim keybindings.
That's not to say that other editors lack a meta-language. Even Notepad has Control-this and Meta-that. But vim and emacs (and my new favorite, kakoune) are all about using the meta language to manipulate text as much as possible, and only doing text entry when text entry is truly called for. Subjectively, I feel more productive using one of these, and completely hamstrung by IDEs, even when they supposedly support vim keybindings.
I wonder if that's the feeling too if you come back to a "normal" programming language after getting reasonably proficient in Lisp.
I see a couple of interesting parallels there - the biggest difference of Vim's modal commands to other control schemes (except maybe Emacs') is that they compose rather well. Add macros to that, and you can define (more or less) abstract editing functionality on the fly. It's basically a similar thing to what Lisp did to ASTs with it's homoiconicity and the macro system on top of it...
I see a couple of interesting parallels there - the biggest difference of Vim's modal commands to other control schemes (except maybe Emacs') is that they compose rather well. Add macros to that, and you can define (more or less) abstract editing functionality on the fly. It's basically a similar thing to what Lisp did to ASTs with it's homoiconicity and the macro system on top of it...
That is a very interesting point. I've been starting to study Racket, and although far from proficient, I can see the analogy. I really appreciate the lack of mental overhead for syntax, and I'm beginning to get a feel for how you might be able to plug things together.
I look at it like this:
When programming, you spend comparatively little time actually writing code. The vast majority of the time is spent reading existing code, and most of the remaining time is modifying the code you read. It actually pretty rare that you sit down and write an entire method or class in one go.
Most editors, however, always have you in the writing state: Just about any key you press will be added to the file you're looking at. If you don't want to add characters to the file, but still need to do things, you need to add modifier keys like Ctrl or Meta or Ctrl-Shift-Meta to the actual key. To move around the file, or between files, or search for more code, requires these longer chords of keypresses. To edit small bits of code require more chords. As such, the things that you do most of the time (reading, modifying) when coding require the most complicated keystrokes.
The default "mode" of an editor like vim is reading. Nearly all of the keys you can press in that mode are just to move the view around or switch files. Eg, the keys to move by a single character (`jkl;`) are all on the home row. To move to the next block of code is simply `]`. To jump to a specific character is `f` + that character. To find some string is `/`, and then `n` jump between matches. And then to copy/paste some code is just `y` and `p`. In any other editor, all of those actions would require one or more modifier keys. So in my mind, vim's primary advantage is that the sorts of things you're doing when coding take many fewer keystrokes, and hardly any modifiers that contort the hand.
And then on top of that, all of the actions one can take in vim can really be thought of as functions that take arguments. So you can use the "copy" action with any movement action (char, line, paragraph, find, etc...), and that's the part that will be copied. Prefix an action with a number, and it'll be repeated that many times.
It's this mindset that few other editors can manage (and even the vim emulators miss some of the really cool stuff), which is why they have have my vim when the pry it from my cold, dead, carpal-tunnel-laden hands.
When programming, you spend comparatively little time actually writing code. The vast majority of the time is spent reading existing code, and most of the remaining time is modifying the code you read. It actually pretty rare that you sit down and write an entire method or class in one go.
Most editors, however, always have you in the writing state: Just about any key you press will be added to the file you're looking at. If you don't want to add characters to the file, but still need to do things, you need to add modifier keys like Ctrl or Meta or Ctrl-Shift-Meta to the actual key. To move around the file, or between files, or search for more code, requires these longer chords of keypresses. To edit small bits of code require more chords. As such, the things that you do most of the time (reading, modifying) when coding require the most complicated keystrokes.
The default "mode" of an editor like vim is reading. Nearly all of the keys you can press in that mode are just to move the view around or switch files. Eg, the keys to move by a single character (`jkl;`) are all on the home row. To move to the next block of code is simply `]`. To jump to a specific character is `f` + that character. To find some string is `/`, and then `n` jump between matches. And then to copy/paste some code is just `y` and `p`. In any other editor, all of those actions would require one or more modifier keys. So in my mind, vim's primary advantage is that the sorts of things you're doing when coding take many fewer keystrokes, and hardly any modifiers that contort the hand.
And then on top of that, all of the actions one can take in vim can really be thought of as functions that take arguments. So you can use the "copy" action with any movement action (char, line, paragraph, find, etc...), and that's the part that will be copied. Prefix an action with a number, and it'll be repeated that many times.
It's this mindset that few other editors can manage (and even the vim emulators miss some of the really cool stuff), which is why they have have my vim when the pry it from my cold, dead, carpal-tunnel-laden hands.
If you're only considering moving your cursor around and editing text, then Sublime Text probably makes sense, but there's a lot more to Vim than just that. Macros, for example, are a powerful part of Vim that save a ton of time and effort, and aren't readily found in other editors.
On the contrary, I do use SublimeText...with Vintage Mode / Vintageous for Vim keybindings, because I find them so incredibly useful.
Came here to make a comment about other utilities in the same vein...but the author already did!
> [4] Or, emacs. Or, really, any other tool that you 1) use constantly; 2) is almost universally applicable; and, 3) makes you more productive.
Nice to see consideration for other tools in a piece like this.
> [4] Or, emacs. Or, really, any other tool that you 1) use constantly; 2) is almost universally applicable; and, 3) makes you more productive.
Nice to see consideration for other tools in a piece like this.
Thanks!
I put VIM in the title because 1) it's got a recognizable identity to pull in readers and, 2) I use VIM. But, in a weird and almost recursive way, editor wars are kinda like language wars. If it gets you that 5% (or more) boost, great! But, the differences between them often washes out.
I put VIM in the title because 1) it's got a recognizable identity to pull in readers and, 2) I use VIM. But, in a weird and almost recursive way, editor wars are kinda like language wars. If it gets you that 5% (or more) boost, great! But, the differences between them often washes out.
Yeah, the most important thing is to know your tools of choice really, really well. vim never made me more productive—being able to do what I needed to in it quickly did. I could just as easily have used emacs (had I learned that first), or atom (had that been around back then) or <insert favorite editor/ide here>.
Yes.
The had-I-learned-it-first concept is something I didn't mention, but do think is important. And, often it works in an inhibiting way. With an IDEA-like rich IDEs -- which I think is a great tool, esp with VIM bindings! -- you get such a boost from things like good contextual auto-complete, that you never feel the need to learn it more deeply.
The had-I-learned-it-first concept is something I didn't mention, but do think is important. And, often it works in an inhibiting way. With an IDEA-like rich IDEs -- which I think is a great tool, esp with VIM bindings! -- you get such a boost from things like good contextual auto-complete, that you never feel the need to learn it more deeply.
This way you can also attract furious members from the church of emacs ;)
But learning Vi is extremely useful, because many editors/IDEs feature a Vi Plugin:
Visual Studio, Qt, Eclipse, Xcode, Atom, IntelliJ and of course Emacs. Learning the basic Emacs shortcuts is likewise useful for terminal (though some shells also have a Vi mode!)
But learning Vi is extremely useful, because many editors/IDEs feature a Vi Plugin:
Visual Studio, Qt, Eclipse, Xcode, Atom, IntelliJ and of course Emacs. Learning the basic Emacs shortcuts is likewise useful for terminal (though some shells also have a Vi mode!)
This is a huge thing I've been thinking about lately.
Very recently I was a pretty staunch advocate for IDEs and thought the whole VIM situation was crazy. It is unintuitive. It doesn't come bundled with lots of useful tools. It takes some configuration if you want nice things (e.g. file tree on the side).
Over winter break I decided to really commit to becoming productive in VIM. I stopped using VSCode and I stayed away from other IDEs, even as I was learning Java Spark and digging into some Python projects.
I didn't notice it at the time, but VIM has made me much more productive, even with my very minimal knowledge (I learn new commands even for basic things all the time). Ultimately, the fact of the matter seems to be that the keyboard->mouse->keyboard transition is really slow. Going to Visual Studio (I'm learning Win32 and I don't want to do that without IntelliSense) after ~2 months in VIM is almost excruciating. I'll be loading up the VIM plugin pretty soon
The long and short of it is, and my advice for everyone who asks is, learn VIM (and other command line tools) as soon as you possibly can. I have no loyalty to the UNIX philosophy or ecosystem, but take it from me, you'll be glad you did.
Very recently I was a pretty staunch advocate for IDEs and thought the whole VIM situation was crazy. It is unintuitive. It doesn't come bundled with lots of useful tools. It takes some configuration if you want nice things (e.g. file tree on the side).
Over winter break I decided to really commit to becoming productive in VIM. I stopped using VSCode and I stayed away from other IDEs, even as I was learning Java Spark and digging into some Python projects.
I didn't notice it at the time, but VIM has made me much more productive, even with my very minimal knowledge (I learn new commands even for basic things all the time). Ultimately, the fact of the matter seems to be that the keyboard->mouse->keyboard transition is really slow. Going to Visual Studio (I'm learning Win32 and I don't want to do that without IntelliSense) after ~2 months in VIM is almost excruciating. I'll be loading up the VIM plugin pretty soon
The long and short of it is, and my advice for everyone who asks is, learn VIM (and other command line tools) as soon as you possibly can. I have no loyalty to the UNIX philosophy or ecosystem, but take it from me, you'll be glad you did.
I use VsVim in Visual Studio, highly recommended.
When I read articles about vi/vim being great for coders I always wonder how you deal with having to use the same part of your brain for writing the code you are writing and to "code vim commands"
I mean, I understand it's attractive to a programmer's mind to be able to do fancy 'replace the next 3 words with x' and so on, and compose them in vim's language, but if I am deep in an algorithm the last thing I want is to have to context switch to "programming my editor"
When doing editing tasks in a more visual as opposed to programmatical way, it feels more that my "coding brain" is free to continue working on the algorithm at hand while some other part of my brain deals with the moving of text around.
Keeping the right cursor key pressed for 1 second is a lot slower than doing some fancy move to the X word in the line, but if engaging my brain to create the composite "move to the X word" command takes me out of the "flow state" I am in, it is way way way more expensive in the long run. In the end what you want is to be the most productive, and the most productive could mean that you are using the editor less efficiently because the more efficient parts of your brain are busy doing something else.
Not sure, maybe somebody that started with vim as their first editor does not have this context switching issue, I personally started with emacs and remained with it and I have my emacs config full of hyper / super / meta / alt / control / shift shortcuts and tons of cool packages, but while I am deep in coding flow state I still use the cursor keys with minimal package help (outside of multiple-cursors and macros sometimes) to avoid getting distracted.
I mean, I understand it's attractive to a programmer's mind to be able to do fancy 'replace the next 3 words with x' and so on, and compose them in vim's language, but if I am deep in an algorithm the last thing I want is to have to context switch to "programming my editor"
When doing editing tasks in a more visual as opposed to programmatical way, it feels more that my "coding brain" is free to continue working on the algorithm at hand while some other part of my brain deals with the moving of text around.
Keeping the right cursor key pressed for 1 second is a lot slower than doing some fancy move to the X word in the line, but if engaging my brain to create the composite "move to the X word" command takes me out of the "flow state" I am in, it is way way way more expensive in the long run. In the end what you want is to be the most productive, and the most productive could mean that you are using the editor less efficiently because the more efficient parts of your brain are busy doing something else.
Not sure, maybe somebody that started with vim as their first editor does not have this context switching issue, I personally started with emacs and remained with it and I have my emacs config full of hyper / super / meta / alt / control / shift shortcuts and tons of cool packages, but while I am deep in coding flow state I still use the cursor keys with minimal package help (outside of multiple-cursors and macros sometimes) to avoid getting distracted.
I am actively using a vim-like control scheme for almost any text I write for about 15 months now. I certainly am not the most proficient in it (in fact, I suspect I could do much better if I weren't "confined" to VS and VSVIM at work - I use Spacemacs privately), but I have enough "training" to make the basic moves I need unconciously. If you come from more limited IDEs or text editors this alone is already well worth it. And at the moment when you understand the basic gist of macros on top of that, it basically becomes a superweapon.
I'm sure there's something to get out of being an "expert Vim user", but even if you're starting out, there's already much to be gained from the simple routines. I find the notion of a "Vim Kata" very compelling as a metaphor, since it's really the repetition that teaches those "reflexes" at first.
I don't know how much an avid Emacs user could get out of it though. I guess that comes down to personal preferences. I couldn't get myself to memorize all the weird key combinations for example, but I quite like Spacemacs' mnemonics system.
I'm sure there's something to get out of being an "expert Vim user", but even if you're starting out, there's already much to be gained from the simple routines. I find the notion of a "Vim Kata" very compelling as a metaphor, since it's really the repetition that teaches those "reflexes" at first.
I don't know how much an avid Emacs user could get out of it though. I guess that comes down to personal preferences. I couldn't get myself to memorize all the weird key combinations for example, but I quite like Spacemacs' mnemonics system.
> I always wonder how you deal with having to use the same part of your brain for writing the code you are writing and to "code vim commands"
I think the transformations you think about map very nicely to vim commands. If you want to move some code around for instance, the action you want in the brain is "delete line" and the vim mapping is "dd". So I'm never thinking about vim commands, I just have an internal mapping for the change I want to the command to do it.
This is where I find the productivity comes from, with a normal editor you go thought->action, thought->action, etc and I find if action is to long it can break the thought part.
I think the transformations you think about map very nicely to vim commands. If you want to move some code around for instance, the action you want in the brain is "delete line" and the vim mapping is "dd". So I'm never thinking about vim commands, I just have an internal mapping for the change I want to the command to do it.
This is where I find the productivity comes from, with a normal editor you go thought->action, thought->action, etc and I find if action is to long it can break the thought part.
This is a great point that I wish I wrote about.
I think this is actually the source of the "steep learning curve" problem. Once you've used it enough, it is an almost orthogonal part of your brain that does thats the VIM command-ing. It becomes more like, "to walk, put one foot in front of the other." You don't actually process that thought when walking.
But, until that point, it absolutely IS the same part of your brain. Until that point, there IS a PAINFUL contention between work brain and editor brain.
I think this is actually the source of the "steep learning curve" problem. Once you've used it enough, it is an almost orthogonal part of your brain that does thats the VIM command-ing. It becomes more like, "to walk, put one foot in front of the other." You don't actually process that thought when walking.
But, until that point, it absolutely IS the same part of your brain. Until that point, there IS a PAINFUL contention between work brain and editor brain.
I'm not a super advanced Vim user (I mostly use hjklbw with numeric prefixes to get around) but it's all muscle memory, and I don't ever feel like I'm context switching.
I'm a diehard Vim fan. I use Vi-motion keybindings everywhere. System-wide. In every single tool I use. I don't ever touch arrow keys. I don't need to. I rarely have to use touchpad. It feels empowering to be able to do things the way I do. I don't think anymore about how and what I need to do to get quickly where I want to be - I just intuitively do it. This is probably how controlling things with your mind would feel. The downside? I can't work using one hand anymore. It just feels weird.
Vim is awesome. It's not an editor - it's a lifestyle. It's telling the machine who's the boss. It's staying "in the zone". It's cutting through the code like slicing butter with hot knife.
So, one day I woke up. I realized that Emacs can be better Vim than Vim. Hold on. Before throwing stones at me do one thing: give an honest and heartfelt try to Spacemacs. I guarantee it - you will be amazed.
Vim is awesome. It's not an editor - it's a lifestyle. It's telling the machine who's the boss. It's staying "in the zone". It's cutting through the code like slicing butter with hot knife.
So, one day I woke up. I realized that Emacs can be better Vim than Vim. Hold on. Before throwing stones at me do one thing: give an honest and heartfelt try to Spacemacs. I guarantee it - you will be amazed.
> let’s say it makes you 5% more productive
> It’s an extra twenty minutes a day
Author presumes 100% of programming time is spent typing/editing.
Is this really the case? I'd wager it's close to 10% for most people.
Author presumes 100% of programming time is spent typing/editing.
Is this really the case? I'd wager it's close to 10% for most people.
It's closer to 10%, but that just makes having a fluid and easy editing experience more important IMO. Editing tasks are interruptions at that level, and you want to make it as easy and quick as possible to get your mental models re-loaded into short-term memory.
I admit, 5% is a subjective prior / fudge-factor. But, statistical white-lies communicate a promise which extends the invitation: try it, see if you're more productive.
I'd love to see some objective stats though!
I'd love to see some objective stats though!
I moved to VIM (ideavim, vimperator) completely once I started feeling uncomfortable in the right palm.
Reducing the number of keystrokes per days is paramount to productivity increase for me, nowadays.
Reducing the number of keystrokes per days is paramount to productivity increase for me, nowadays.
If you like IdeaVim and Vimperator, try using a plugin called AceJump [1]. Like Vimperator, you can map the F key in normal mode to activate AceJump, then start typing any visible character or string on the screen. We are working on multi-monitor support and history, and would love to get your feedback. Full disclosure: I am a contributor.
[1]: https://github.com/johnlindquist/AceJump
[1]: https://github.com/johnlindquist/AceJump
I can't claim to have ever "tried" to get into vim - in the sense of ditching my daily driver (Sublime/VS Code) and going 100% vim. I've done the vimtutor, I even know how to do basic text editing (cut, copy, paste, find-and-replace, visual mode highlight) in vim, plus some of those "magic" things where you can repeat an action multiple times (:2wi or whatever). And I'll happily fire up vim if it's something really quick, like making a list in a plain text file or something.
So what's kept me from going 100% vim?
1. Plugin/add-on support - I have no clue what's going on here. There's no clear guidance on what to use (vundle? pathogen?). I haven't really grokked how plugins really work - where do they come from? how do I search for them? where are they really installed? how are they organized in the install directory? do I need to care? etc (I'm aware this is all documented somewhere, and maybe I just need to make more of an effort). Whereas in something like Sublime Text there's an easily installable package manager that takes care of all these things for you. And if you really care to learn, you can drop into one of the packages and find easy-to-understand Python and JSON. Versus vimscript, weird config files and whatever else vim uses to configure things.
2. Multi-file support - Sublime has a Cmd + T fuzzy filename finder right out of the box. With vim (for a beginner) your choices are either: a) open multiple terminal windows with a single file in each, Cmd + Tab endlessly or b) open multiple files in the same editor and drop out of insert mode every time you want to switch files (way more keystrokes than Cmd + T or Ctrl + Tab; maybe there's a toggle file shortcut in Vim also). I'm aware that there exist plugins for fuzzy-file searching in vim also, but because of 1 I don't know how to find or install them.
3. Buffers and marks - I'm vaguely aware they exist. I'm not sure what they do and why they're important. Again, this one is probably on me rather than the tool itself.
So what's kept me from going 100% vim?
1. Plugin/add-on support - I have no clue what's going on here. There's no clear guidance on what to use (vundle? pathogen?). I haven't really grokked how plugins really work - where do they come from? how do I search for them? where are they really installed? how are they organized in the install directory? do I need to care? etc (I'm aware this is all documented somewhere, and maybe I just need to make more of an effort). Whereas in something like Sublime Text there's an easily installable package manager that takes care of all these things for you. And if you really care to learn, you can drop into one of the packages and find easy-to-understand Python and JSON. Versus vimscript, weird config files and whatever else vim uses to configure things.
2. Multi-file support - Sublime has a Cmd + T fuzzy filename finder right out of the box. With vim (for a beginner) your choices are either: a) open multiple terminal windows with a single file in each, Cmd + Tab endlessly or b) open multiple files in the same editor and drop out of insert mode every time you want to switch files (way more keystrokes than Cmd + T or Ctrl + Tab; maybe there's a toggle file shortcut in Vim also). I'm aware that there exist plugins for fuzzy-file searching in vim also, but because of 1 I don't know how to find or install them.
3. Buffers and marks - I'm vaguely aware they exist. I'm not sure what they do and why they're important. Again, this one is probably on me rather than the tool itself.
#1
I have been using pathogen since I started using vim, I can recommend it. (copy paste directions to install: https://github.com/tpope/vim-pathogen) And this is where you can find vim plug-ins: http://vimawesome.com/
After installing pathogen, to install a plug-in:
cd ~/.vim/bundle
git clone <url>
and you are done in most cases, some require adding a few lines on ~/.vimrc.
#2
There are multiple ways to work with multiple files. There are tabs in vim, split screens, files in buffer etc, these are all without plug-ins.
I have been using pathogen since I started using vim, I can recommend it. (copy paste directions to install: https://github.com/tpope/vim-pathogen) And this is where you can find vim plug-ins: http://vimawesome.com/
After installing pathogen, to install a plug-in:
cd ~/.vim/bundle
git clone <url>
and you are done in most cases, some require adding a few lines on ~/.vimrc.
#2
There are multiple ways to work with multiple files. There are tabs in vim, split screens, files in buffer etc, these are all without plug-ins.
> I have been using pathogen since I started using vim
Thanks for the recommendation. The trouble (and again, maybe this is down to my lack of research) is that other commenters will recommend Vundle with links to similar resources (and I've tried both Vundle and Pathogen, sometimes one after another, ruining my ~/.vim dir :P). I can find all of these recommendations myself but (maybe I'm wrong here) there's no clear winner in the vim ecosystem. There's no single de-facto manager that's used by 90% of all vimmers. Hell, I know people who I think maintain their vim plugins and config and scripts using only git, so maybe a package manager isn't even that much of a priority for many users.
> There are tabs in vim, split screens, files in buffer etc, these are all without plug-ins.
Agreed, but cursory research tells me that you have to type multiple characters to switch between files. For example, the documentation page on buffers: http://vim.wikia.com/wiki/Vim_buffer_FAQ lists about 20 different buffer navigations (bNext, bnext, bprevious etc (and why there's no bPrevious is a big fat ¯\_(ツ)_/¯ )) but not a single command for toggling between two open files, a pretty common use case. Whereas text editors like Sublime leverage the already-known (from using browsers) Ctrl + T shortcut and provide you this really necessary action in fewer keystrokes (1 vs Esc (or your Esc shortcut key) + :bNext = 7 assuming there's no shortcut for "Next" though there probably is).
> There are multiple ways to work with multiple files.
And maybe that's the problem. There are multiple ways to do everything (multiple files, plugin management etc) rather than one "best" or "recommended" way that works for most users. This is understandable for a hacker's tool; options and flags rather than intelligent defaults. But it leaves newcomers somewhat adrift. I'm not criticizing the tool itself; Bram Molenaar and co. are doing an amazing job and we should all be grateful for such a high-quality tool that's freely available on practically every nix. Something like a canonical beginner's vim config that's aggressively maintained and everyone knows about would be nice though.
EDIT: How do you type a "*"?
EDIT: Looks like switching buffers (which I think is the same as toggling between files) is :b#, which is still 4 characters vs 1. http://vim.wikia.com/wiki/VimTip686#Switching_to_the_previou...
Thanks for the recommendation. The trouble (and again, maybe this is down to my lack of research) is that other commenters will recommend Vundle with links to similar resources (and I've tried both Vundle and Pathogen, sometimes one after another, ruining my ~/.vim dir :P). I can find all of these recommendations myself but (maybe I'm wrong here) there's no clear winner in the vim ecosystem. There's no single de-facto manager that's used by 90% of all vimmers. Hell, I know people who I think maintain their vim plugins and config and scripts using only git, so maybe a package manager isn't even that much of a priority for many users.
> There are tabs in vim, split screens, files in buffer etc, these are all without plug-ins.
Agreed, but cursory research tells me that you have to type multiple characters to switch between files. For example, the documentation page on buffers: http://vim.wikia.com/wiki/Vim_buffer_FAQ lists about 20 different buffer navigations (bNext, bnext, bprevious etc (and why there's no bPrevious is a big fat ¯\_(ツ)_/¯ )) but not a single command for toggling between two open files, a pretty common use case. Whereas text editors like Sublime leverage the already-known (from using browsers) Ctrl + T shortcut and provide you this really necessary action in fewer keystrokes (1 vs Esc (or your Esc shortcut key) + :bNext = 7 assuming there's no shortcut for "Next" though there probably is).
> There are multiple ways to work with multiple files.
And maybe that's the problem. There are multiple ways to do everything (multiple files, plugin management etc) rather than one "best" or "recommended" way that works for most users. This is understandable for a hacker's tool; options and flags rather than intelligent defaults. But it leaves newcomers somewhat adrift. I'm not criticizing the tool itself; Bram Molenaar and co. are doing an amazing job and we should all be grateful for such a high-quality tool that's freely available on practically every nix. Something like a canonical beginner's vim config that's aggressively maintained and everyone knows about would be nice though.
EDIT: How do you type a "*"?
EDIT: Looks like switching buffers (which I think is the same as toggling between files) is :b#, which is still 4 characters vs 1. http://vim.wikia.com/wiki/VimTip686#Switching_to_the_previou...
Watch this three minute video or view the concise notes below it for some very nice tips on handling buffers.
http://vimcasts.org/episodes/working-with-buffers/
> You can quickly jump between the active buffer and the alternate buffer using the command <CTRL-^>. Pressing it again takes you back to where you were before.
If you don't like the <CTRL-^> command for this, you could map it to something else, such as the tab key, with a line in your .vimrc:
> There's no single de-facto manager that's used by 90% of all vimmers.
Most recently updated plugins work with each of the managers. I use a handful of plugins with Pathogen, but the same plugins could be used with another manager.
However, the latest release of Vim now includes a built in plugin system, does that satisfy your need to have one blessed version?
https://shapeshed.com/vim-packages/
----
> 20 different buffer navigations
Keep in mind, all these commands can be shortened to the smallest unique prefix. So with `:bn` and `:bp` you can go forward and backward. But if you don't like typing three characters, just sacrifice something else by remapping it in your .vimrc!
----
> toggling between two open files, a pretty common use case
When I am working on two files at once, I'll usually put them both up at the same time. If I have "a.txt" open and I also want to work on "b.txt" I can type `:vsp b.txt" and now I have them up side-by-side. I can switch between them with whatever command I have set up to do that.
http://vimcasts.org/episodes/working-with-buffers/
> You can quickly jump between the active buffer and the alternate buffer using the command <CTRL-^>. Pressing it again takes you back to where you were before.
If you don't like the <CTRL-^> command for this, you could map it to something else, such as the tab key, with a line in your .vimrc:
nnoremap <TAB> <C-^>
> There's no single de-facto manager that's used by 90% of all vimmers.
Most recently updated plugins work with each of the managers. I use a handful of plugins with Pathogen, but the same plugins could be used with another manager.
However, the latest release of Vim now includes a built in plugin system, does that satisfy your need to have one blessed version?
https://shapeshed.com/vim-packages/
----
> 20 different buffer navigations
Keep in mind, all these commands can be shortened to the smallest unique prefix. So with `:bn` and `:bp` you can go forward and backward. But if you don't like typing three characters, just sacrifice something else by remapping it in your .vimrc!
----
> toggling between two open files, a pretty common use case
When I am working on two files at once, I'll usually put them both up at the same time. If I have "a.txt" open and I also want to work on "b.txt" I can type `:vsp b.txt" and now I have them up side-by-side. I can switch between them with whatever command I have set up to do that.
Thanks, that video was pretty good and helped me understand buffers. If you'll indulge me a bit more though, why does Vim warn you while switching out of an unsaved buffer (and make you use !) if it's still going to keep your changes when you come back?
> However, the latest release of Vim now includes a built in plugin system, does that satisfy your need to have one blessed version?
It absolutely does. I'm going to try it out!
> However, the latest release of Vim now includes a built in plugin system, does that satisfy your need to have one blessed version?
It absolutely does. I'm going to try it out!
Not sure if you'll find this delayed comment, but I can give it a shot.
There is a note on the linked video page about `set hidden`, but it doesn't spend much time explaining it. If we open Vim and type `:help hidden`, we get the following:
Turning `hidden` on would remove the warning, you could switch away from an unsaved buffer with `:bn`.
So if you want to always work with unsaved hidden buffers floating around (view them with `:ls`!), you could add `set hidden` to your .vimrc. Alternatively, you could set up a command to automatically execute a save action every time you tried to switch away from an unsaved buffer. Notice that `autowrite` is mentioned in the help text above. Running `:help autowrite` shows:
Hope this helps! One of the pain points of vim is that many of the defaults end up being somewhat unexpected choices. Many people get over that by just looking up someone's post online and copying in a bunch of settings. When you do that, you don't end up learning much about navigating vim and understanding the configuration process. You just end up with a new set of defaults that might also not quite be what you want. I try to keep my .vimrc pretty plain until I realize something could be better, then spend a moment to figure out how to do that and add it in.
There is a note on the linked video page about `set hidden`, but it doesn't spend much time explaining it. If we open Vim and type `:help hidden`, we get the following:
'hidden' 'hid' boolean (default off)
global
{not in Vi}
When off a buffer is unloaded when it is abandoned. When on a
buffer becomes hidden when it is abandoned. If the buffer is still
displayed in another window, it does not become hidden, of course.
The commands that move through the buffer list sometimes make a buffer
hidden although the 'hidden' option is off: When the buffer is
modified, 'autowrite' is off or writing is not possible, and the '!'
flag was used. See also windows.txt.
To only make one buffer hidden use the 'bufhidden' option.
This option is set for one command with ":hide {command}" :hide.
WARNING: It's easy to forget that you have changes in hidden buffers.
Think twice when using ":q!" or ":qa!".
Turning `hidden` on would remove the warning, you could switch away from an unsaved buffer with `:bn`.
So if you want to always work with unsaved hidden buffers floating around (view them with `:ls`!), you could add `set hidden` to your .vimrc. Alternatively, you could set up a command to automatically execute a save action every time you tried to switch away from an unsaved buffer. Notice that `autowrite` is mentioned in the help text above. Running `:help autowrite` shows:
'autowrite' 'aw' boolean (default off)
global
Write the contents of the file, if it has been modified, on each
:next, :rewind, :last, :first, :previous, :stop, :suspend, :tag, :!,
:make, CTRL-] and CTRL-^ command; and when a :buffer, CTRL-O, CTRL-I,
'{A-Z0-9}, or `{A-Z0-9} command takes one to another file.
Note that for some commands the 'autowrite' option is not used, see
'autowriteall' for that.
Hope this helps! One of the pain points of vim is that many of the defaults end up being somewhat unexpected choices. Many people get over that by just looking up someone's post online and copying in a bunch of settings. When you do that, you don't end up learning much about navigating vim and understanding the configuration process. You just end up with a new set of defaults that might also not quite be what you want. I try to keep my .vimrc pretty plain until I realize something could be better, then spend a moment to figure out how to do that and add it in.
Thanks again!
You should give spacemacs a look: vim mode in emacs plus all the stuff you are missing from the other editors. I don't use it because I am a happy vim user and more recently vscode using vim mode : the best of both worlds.
I've never used emacs, so it's not immediately obvious to me how that's better. I'll give it a shot though, thanks for the recommendation.
[deleted]
> Most of the time, you shouldn’t use the Best Paradigm (TM) that exists. You should use the one that is good enough and works well in the language you are using.[3] Clever only gets you geek cred; conventions let you communicate well, both to others and to yourself six months later. That really cool pattern you learned that one time? You may never use it, and even if you do, the marginal gain probably won’t be that impressive.
Aren't these all reasons to not bother learning vim?
Aren't these all reasons to not bother learning vim?
[deleted]
I find using Vim more natural when I'm spending time in the command line. I'm an entrenched Windows user but I love the power of the linux command tools.
Now thanks to the GNU Tools packaged with Git, you get Vim and OpenSSH as lovely extras. It's really nice to be able to switch back and forth between editing on Linux via SSH in Vim and then back in Windows.
If you're searching around and moving files via the DOS prompt, getting your daily Docker/Vagrant fix it becomes much more natural just to open Vim edit the file and close it.
Plus you can add the solarized colours to the DOS prompt and you get lovely syntax highlighting too.
Now thanks to the GNU Tools packaged with Git, you get Vim and OpenSSH as lovely extras. It's really nice to be able to switch back and forth between editing on Linux via SSH in Vim and then back in Windows.
If you're searching around and moving files via the DOS prompt, getting your daily Docker/Vagrant fix it becomes much more natural just to open Vim edit the file and close it.
Plus you can add the solarized colours to the DOS prompt and you get lovely syntax highlighting too.
You know Cygwin has been around for ages and has done this forever. You didn't need to wait for some big bundle of git to arrive on Windows for this.
I don't think you need to wait for anything; I think he's describing MinGW that comes with a Windows install of Git. It's been around for a long time.
Cygwin vs MinGW is a whole other argument, of course.
Cygwin vs MinGW is a whole other argument, of course.
Yeah the MinGW - it's just that Git packaged them all up nicely, previously I always found there was a few missing tools. I find it much nicer to be able to use those inside DOS.
Yes, I was using Cygwin a decade ago - it was the most painful experience.
It's got nothing to do with Git - just that Git bundles the most up to date versions of GNU tools compiled for Windows. There were pre-cursors to Git, but Git packages them all nicely.
Just for sentimental reasons I love using DOS, same as any Linux user loves their shell. So having the tools natively in DOS is a much nicer experience.
It's got nothing to do with Git - just that Git bundles the most up to date versions of GNU tools compiled for Windows. There were pre-cursors to Git, but Git packages them all nicely.
Just for sentimental reasons I love using DOS, same as any Linux user loves their shell. So having the tools natively in DOS is a much nicer experience.
> it makes you 5% more productive
Is there a study, or you just feel like it?
Is there a study, or you just feel like it?
Full quote, for context:
Being conservative, let’s say it makes you 5% more productive.
It might no be too hard in this case, since you're really testing editing speed not code productivity. You could take a random selection of (small) git commits and time how long it takes people to recreate them. That maybe gives Vim an unfair advantage actually since the IDE features help more while actually composing code, rather than just editing text.
Still I think it could be measured.
Still I think it could be measured.
I think the focus on speed is counterproductive. Increased productivity isn't the only — or even the most important — measure of value.
I enjoy using Vim (Emacs Evil mode these days) because I can edit more fluidly without having to shift focus and context switch. My hands stay on the keyboard, my eyes stay on the screen, and I don't have to think about "how" to achieve my goals — I just think about what I want to achieve and muscle memory takes care of the rest.
I might edit more quickly, but that's a side effect of using a tool that allows me to focus deeply and maintain that focus for longer: both of which are vital to flow and satisfaction with my work.
I enjoy using Vim (Emacs Evil mode these days) because I can edit more fluidly without having to shift focus and context switch. My hands stay on the keyboard, my eyes stay on the screen, and I don't have to think about "how" to achieve my goals — I just think about what I want to achieve and muscle memory takes care of the rest.
I might edit more quickly, but that's a side effect of using a tool that allows me to focus deeply and maintain that focus for longer: both of which are vital to flow and satisfaction with my work.
Ignoring generalities. For me, there are clearly times vim is the more efficient tool. I find that to be more often the case than not. At a minimum, learning it allows me to think about things differently than the standard wysiwyg editors. These both make me a better dev. But ultimately, using vim makes me happy. That's what matters to me, and should matter to others as they pick their tools.
I've been interested in using vim and am not completely useless at using it, but I haven't quite been able to commit to it. The main reason is that I'm not sure it's any faster than using IntelliJs products well. Last time I mentioned to a coworker who is a vim user, that I was thinking if switching to it, he said he was thinking of switching to Idea after seeing me use it.
Buried in my footnote is the real gist is: learn your editor, deeply.
IntelliJ is a great tool, too.
IntelliJ is a great tool, too.
VIM'er here. I use IntelliJ-Pycharm when i'm really strappin in for a good DEV session. Plus you get the ideaVim plugin and i've got the same VIM magic I know and love. Plus all the fancy IDE stuff. Some will say you can upgrade VIM to IDE level (project tree, auto complete, other fancies) which is totally true. I dont got time for dat.
Other bonus for vi is that you are now capable of editing files on any unix server in the world.
Other bonus for vi is that you are now capable of editing files on any unix server in the world.
spacemacs is a pretty well integrated, community sourced configuration of emacs that has a lot of sane defaults out of the box. add a few layers for your favorite languages and you are off and running. magit and org mode are both excellent reasons to use emacs. the vim bindings are some of the best i have seen in an emulator as well.
you can always learn vim stuff by using a plugin for your favorite editor. I'm frustrated quite a bit if I have to use an editor without basic vi shortcuts at the very least.
Thanks I'll start there. I keep feeling like I'm missing out on something by not being a Vim expert.
the basics of vim are easy... it's a language to manipulate text with mnemonic shortcuts for the most part and composeable actions.
`daw` is delete around a word(includes the ending space if there).
`ciw` is change inner word.(change the word under the cursor by deleting it and leaving you in insert mode to make changes).
`ci"` is change inside the double quotes.
p is put or paste
d is delete
c is change
f is find
a is insert [a]fter
first answer here[1] is a classic.
1. http://stackoverflow.com/questions/1218390/what-is-your-most...
`daw` is delete around a word(includes the ending space if there).
`ciw` is change inner word.(change the word under the cursor by deleting it and leaving you in insert mode to make changes).
`ci"` is change inside the double quotes.
p is put or paste
d is delete
c is change
f is find
a is insert [a]fter
first answer here[1] is a classic.
1. http://stackoverflow.com/questions/1218390/what-is-your-most...
I used standalone Vim for ~6 years and now use IdeaVIM with Jetbrains products for most of my work–it's a fantastic combination.
agreed, 100%. I used to be a GUI diehard. Then, I was told about emacs and became an emacs fanatic. But the difference between emacs and vi/vim is that you can count on vim not only being on any system anywhere, but behaving in almost the exact same way anywhere.
vim is timeless.
vim is timeless.