Then I saw someone using Vim. I was instantly hocked. The sheer speed of everything happening in the screen, I needed to learn that. And so I did and it’s been an amazing ride.
It’s a pain at the beginning, the amount of time I invested in my .vimrc will probably never payoff, mathematically speaking. But the joy and delight you get from using it everyday, the freedom and efficiency is just addictive.
It’s not for everyone, I was raised on the Mac paradigm, where “modes are evil”, so it was a step learning curve. But few programs have brought me this much joy and excitement over the years.
Some people just like playing with tools. They do it for loads of reasons, but end of the day it’s basically a hobby tangentially related to software development.
I torment a friend of mine who talks all the time about VIM and their most recent config/workflow. But end of day, he’s happy and having fun while being productive.
I normally build in a terminal anyways so this was a pretty nice little speedup for iterating on static analysis results or a build problem.
When you're not proficient with the necessary tools, you're interrupting your flow with what you consider mundane. That you consider text editors mundane is more reason to move as much of that process into muscle memory as possible, not less!
Why are we pretending like mastery of our tools is unimportant? I hear this sort of opinion most eagerly expressed by engineers who in fact are quite handy with vim! Is this some new kind of flex where we're all pretending to take a purely academic approach to programming instead of becoming proficient with the tools of our trade?
Ctrl+F + what you are looking for
PgUp PgDown plus visual scan
Home, End, arrows (plus potentially control) for pinpointing the exact spot. Shift for block marking.
Ctrl+C (or X), Ctrl+V for moving stuff around.
No reason to touch mouse or learn cryptic shortcuts.
On the other hand, having to constantly hold Control/Alt, including long chords (e.g. with prefix + count), feels much worse for me. I use Emacs keybinds on the terminal (outside of vim), but I can't imagine having to constantly press modifiers. It's not as comfortable as switching to a mode where those actions are explictly first-class.
20g line number
/ find what you are looking for
same for pgup and pgdown
i think what you're describing sounds a bit like visual mode which is just v
d and p for cut and paste if moving stuff around needs to be done (dd for whole line, 5dd for 5 lines, v and then j a few times in visual mode before d or y for yank (copy), etc...)
Note how you don't have to strain your pinky to hit ctrl for any of these?
Note how insanely context-dependent all these are? How it's completely different commands for what is essentially the same operation?
Keys can be remapped (I have CapsLock mapped to Ctrl).
It's just a different modality mine just exists a little closer to where my fingertips chill on the home row
Am I crazy? Isn't it conflicting? Maybe those two groups don't overlap at all? Then do great typists believe measuring lines of code to be a good idea?
And being proficient at using your code editor doesn't require or exclude being fast at typing. Between the two I personally would chose mastery of vim/emacs or some other IDE over having a typing speed faster than 80 WPM. Sure, both would be great, but if I have to choose one I know which I prefer.
Full disclosure: I type on a QWERTY layout at an average of 65 WPM.
One thing I'd add is that some stuff like Home Row Mods, Caps Lock as ESC and enhancements like that seem to me like a larger productivity booster than the jump from 70 WPM to 100 WPM. But even so I might be wrong on that because I personally haven't experienced writing faster than 70 something WPM at my best.
Anyway, rant over and I apologize if I come off as rough. It's just something that's been nagging at the back of my mind and I still don't know how to properly put it into words.
As far as typing speed, the difference between 10 wpm and 40 wpm is far greater than 70 wpm and 100 wpm. You don't have to hit 100 wpm to be a good programmer, but I have a hard time believing you can be one hunting and pecking at 10 wpm. (With exception made for the blind.)
Its hard to say if what you program will ultimately be better or worse as being used to micro interruptions can mean more diligence as much as they can mean forgetting an important caveat. But generally I think it means you are progressing at a slower rate toward an integrated group of skills.
For editors and IDEs it can be quite similar for refactoring, debugging and analysis of the code base. The worse you are at using them or the more indirect your proximity to the exact code base of the version you are working with, the more you rely on building/maintaining mental models which has its benefits and dangers.
I think its very hard to say anything is right or wrong. I do think that the question of where you expect to be in terms of needing each skill as your mastery of others grows is the question.
I'm not on board with shaming people, nor do I think that lightning speed typing is needed. However, one I want to type my lines of code, no matter how few they might be, it's about translating thoughts into code as easily as possible. It helps not having to bother with the details of typing, but the typing more or less taking care of itself. Keeps the zone and the focus on the code, and not on the keys.
I used this to learn one hand typing when I was bored.
And when I write I just need to see the keyboard with the corner of my eye and my fingers just find the right keys as I'm pecking, purely through muscle memory that I've gained with zero effort just by years of experience.
He might obviously be in the 80+ range irl.
But in all, he types fast enough to write Linux.
Typing speed is important for typists. For programmers, I’d say that even a 50-80 wpm rate is adequate for getting your thoughts down on the file and off to the compiler.
On the other hand, tools like Vim, Kakoune and Helix shouldn't be treated like your average Java IDE, for example, which shifts the line of what I'd say is reasonable learning investment. What you're dealing with there is a programming language for text manipulation. If you're fluid enough in it, you open your mind for solutions you'd never have considered before. I'd say you'd need at least intermediate Vim skills and should know macros until that effect kicks in.
I have quite some anecdotes about e.g. creating integration tests where my colleagues wouldn't test something properly just because doing so would involve 10 minutes of drudge work in their simplistic editors, instead opting for "deploy & pray" when the task was totally doable in a couple of seconds with a Vim macro. I find that at least in this regard (as for all programming languages), Benjamin Lee Whorf's quote certainly holds true: "Language shapes the way we think and determines what we can think about."
That's why I also think GP had a point. I would probably be much more in your line of thought if we were only talking about the usual contestants like refactoring snippets etc. here, although even having them handy will already influence how many of us work with our code.
Edit: As another analogy, I feel that modal editing has about the same effect on thinking as switching from roman numerals to arabic ones. The reason why it hasn't completely caught on is just that it's less intuitive and text manipulation is not as fundamentally important as calculations for our civilization.
I really very much doubt this. Sounds like an application of rose-tinted glasses and wishful thinking to some one-off task that then is extrapolated to all tasks.
As for one-off tasks: Yes, that's what Vim bindings are good for. Just like AWK-Scripts are great for throw-away scripts. Being able to perform simple one-off tasks quickly is, incidentally, a skill I find to be far too rare even in programmers. I mean, I would've thought at least us techies see the benefit in knowing how to teach the computer to do the menial tasks for us.
No. My doubt extends to "omg vim is so amazing that these tedious tasks take seconds unlike in these primitive text editors".
Because my experience at work has been consistently the exact opposite: vim users routinely take longer time for most tasks precisely because it's a rather primitive text editor, and not a code assist tool.
I won't beleive your assertion, however, that this invalidates the benefits of learning Vim bindings (especially since respective emulation layers are at least passable in pretty much any editor or IDE worth its salt).
If you're talking about normal minute-to-minute text handling and creation of text files without language assist (scripts, cucumber tests, any programming task not blessed by your IDE's refactoring integration) on the other hand, we're at the point where I have trouble believing you.
I am. Because we are talking about these mythical Java programmers who couldn't do something that Vim would have done in seconds
> I won't beleive your assertion, however, that this invalidates the benefits of learning Vim bindings
And the reason to learn them is because there's a fairy tale of some programmers not doing the job that we're led to believe could be solved in seconds in vim.
> If you're talking about normal minute-to-minute text handling and creation of text files
Are we? Let me remind you: "I have quite some anecdotes about e.g. creating integration tests where my colleagues wouldn't test something properly just because doing so would involve 10 minutes of drudge work in their simplistic editors, instead opting for "deploy & pray" when the task was totally doable in a couple of seconds with a Vim macro."
Oh look. We're literally talking about programming.
> we're at the point where I have trouble believing you.
Let's start with your fairy-tales before we come to believing or disbelieving what I wrote.
But then, I'd guess from your tone that this won't stop you from misreading another comment of mine and accusing me of lying, so I'll just wish you a nice weekend instead.
Yes and no. My very first reply pointed out exactly what I found incredible in your story.
If we're sticking to anecdotal data, over 22 years as a programmer I've never seen those amazing feats of vim voodoo you're talking about.
> But then, I'd guess from your tone that this won't stop you from misreading another comment of mine and accusing me of lying
Really? Misreading? Go and read mu very first comment, will you?
So yeah, you're probably right that Vim techniques are far better when you're editing those sorts of files, but those really do make up the tiniest fraction of my time, and everything else is covered by IDE refactoring tools. And if I had the choice, I would always rather have the better IDE tooling than the improved text editing, so this doesn't really sell me on the whole thing.
I would like to try Vim-mode for VSCode at some point, because I can imagine that being a kind of "best of both worlds" thing, but I've not really got round to it yet.
> I hear this sort of opinion most eagerly expressed by engineers who in fact are quite handy with vim!
But to me, that makes me think that you should wonder whether there's something to that. For me, you're right, I did get really handy with vim at one point. After I had been using it to a very basic level for two or three years, I felt kind of sheepish and guilty and endeavored to learn it properly. So I bought into doing it "right" for awhile, wrote a bunch of custom script to customize it, the whole shebang. And my conclusion after that was that it wasn't really worth it. I went back to just using the basic stuff. This is also, importantly, supported in every IDE's keybindings, so I can use modal navigation and editing anywhere without needing to customize anything, which is pretty great.
Then vim ain't it.
My "vim-empowered" colleagues spend significantly more time trying to find symbols, related configs and tests, function definitions and interface implementations than I do. Because their hodge-podge collection of vim plugins and extensions rarely amounts to anything more than a full-text search across the whole project.
But sure, you can count the number of lines where you need to go and then the number of characters/words you need to move in the line and code it in 3 characters. By the time you've done that I've clicked there with the mouse, found the definitions and done project-wide refactoring.
I think it is just not so tricky in the first place. If you start out with “you can use hjkl for directions, and y for copy, d for delete, these can be combined with directions and prepended with numbers; remember the modes, and :w and :q” vim is already as good as most others editors. Then I’d just start using it, rather than trying to learn from the top.
My filter for when I should learn a new feature is when it solves a task I find repetitive and annoying (or I will make a post on Hackernews that says learning Vim is useless, to get a list of features that people actually use day to day). Since we all have different idiosyncrasies, this filter will be different from person to person, so I don’t really get the idea of a guide.
That said, I’m just describing what worked for me; if someone wants a guide they should go for it, we all learn differently after all.
There! You said it so well... that's the #0 reason why I go RTFM'ing, because most likely my problem fits a pattern someone already encountered and figured a solution for. Or nobody did and I put together a less annoying workflow to deal with it.
Sometimes the effort is worth it, but often it is just fun trying out new things/techniques.
For example, is it really still OK to have little to no visual feedback when entering commands with range/count prefixes, or to have to fall back to custom commands and configs in order to search for strings containing "/"? Or have commands with tiny edit distance between them do radically different things (e.g. "w! " and "w !")? Vim's modal editing implementation also can't handle non-Latin keyboard layouts so I find myself switching keyboard layouts all the time (e.g. normal mode->insert mode->layout switch->type some text->layout switch->normal mode).
This issue is solved by langmap.
Besides that, I just find the whole method of navigating (skipping words, skipping an X amount of lines) counterintuitive. It's nothing I can get used to, I will always miss the precision of just taking the mouse and getting the cursor exactly where I want it in one sweep and click.
It really doesn't need to be this mystical uber-hacker thing to be useful.
I want to select from here to just after that letter P. With hjkl and visual mode I’m already halfway there. Whenever I try something clever I always find myself thinking “is that the end of a block? Or maybe I should cut directly to P but oh there’s another one on the line above so it’s the second, need to amend” etc etc etc.
Also "dd" and "p" a lot to move lines around and "J" to consolidate them.
So maybe I do use a pretty large amount of functionality pretty frequently :)
I've been thinking maybe that other comment nailed it and most of us who downplay how useful it is to really learn vim have just already done that and forgotten that it was really useful.
This means it can help keep out intrusions about editor maneuvering from your mind at work.
Some people see no value to this and fill their vim bundle with plugins that slow everything down a lot, but some of us really enjoy just surfing the high source and watching our thinking materialise on the screen seemingly effortlessly and immediately.
I use IntelliJ all day every day too, but it's mainly for admin and control stuff and certain types of refactors it can handle better. It's to my code editing as gitk is to my version control. It's where I run the tests, all the plugins, can get docs prerendered, things like that.
It's not where I can quickly navigate the code base, jumping immediately from file to file as fast as a fuzzy hint can get me, and then within the file as fast as Space+string can get me. You might have a keyboard layout with a forward slash easily available, mine doesn't so in normal mode space is /. Navigating in vim can be hjkl w b and so on, sure. But it can also be search. Just say the place and poof, you're there. It's wrong but very similar to where you want to go? n for next or try to name a new place.
This doesn't work in IntelliJ and it's a little off in emacs. I mean you can certainly technically do it but it's slow. There's waiting and the application twitches when it tries to imitate the vim way. Pretty much all finding tasks can be powered by fzf and ripgrep, and unlike IDE:s vim just does the thing when you tell it to. There's is no wait and then a dialog, there is none of 'ok, understand but Ide competent, knows many things, need more info before can do the thing' that tools like IntelliJ and Visual Studio do.
You also want jk to be Esc for sure. Esc is far away and CapsLock is for Control.
Ctrl-[ is the same keycode as escape in terminals, and it's much easier to reach. For me, remapping jk in insert mode results in lag after typing 'j'.
It only creates lag if you actually want to type 'jk'. Otherwise, you keep typing like normal, and it doesn't matter. You should be able to config the delay, too. I use `fd`, and I can count the number I've noticed it.
If you want a plugin that makes it so that the j appears immediately regardless of whether you're trying to invoke the keymap or not, you can use something like https://github.com/nvim-zh/better-escape.vim
That little lag on the j doesn't matter, when you notice you're already a few keys ahead anyway.
> 'ok, understand but Ide competent, knows many things, need more info before can do the thing'
Every month or two I'd read a manpage for something and really experiment with using all the facilities - most of them wouldn't stick, but every now and again some would.
Just pick something like "less" or "bash", read the manpage, and try using something you've not done before. It's very helpful.
For Vim I went through the tutorial a few times a long time ago, and that really helps. (For twenty years I used emacs for "everything", and vim solely for email, via mutt and later my own client.)
It just removes a lot of frustration, that's the thing for me. Working less on fiddling with text is focusing more on the conceptual level. Again, I'm not claiming the output is better, I'm just happier doing it.
It true that thinking takes more time than typing/editing even you type slow and don't use any hotkeys for editing, but I have a feeling that the less time/effort I spent on typing/editing the less my thinking is interrupted.
With some practice one can use quite a few vim features relying on 'muscle memory' to spend less time/effort on editing and concentrate on what matters - thinking.
Do you think everything through and then implement it? I do most of my thinking as I type.
Though I no longer program, I am still a huge VIM enthusiast, but no it is not necessary to use VIM. I just love it because it made me more efficient, but at times I think that writing code really really fast might actually be a bug and not a feature.
For editing code it's amazing though. People looking over my shoulder used to think I was a wizard.
Is the text editor really a bottleneck for anyone? I find that no matter how slow I type, I need to spend more time thinking of what to type anyway, if I’m doing anything interesting.