Most advanced guides throw a lot at you at once. Digesting one or few commands at a time works better for me to really make it stick (and that is the goal right?)
I notice it mentions Ctrl-a and Ctrl-x which "increment or decrement any number after the cursor on the same line". I hate these shortcuts because several times I've accidentally pressed them (e.g. on some level thinking I'm in Spacemacs or in readline) and introduced a hard-to-find bug into my code without knowing it.
Having suffered through learning highly configurable software tools independently enough times, I agree completely with "digesting one or few commands" at a time works better for me too.
Spitballing:
We could probably make a general solution for organically producing "learning guide" if power users 1) share their custom configurations and share the frequencies of commands they use.
Start with the general configuration, knowing nothing about the commands the tool offers. The learning guide is just a queue of "here's the most common config edit that you don't have" and "here's the most common command that you don't know about."
We are already share configs with eachother via the dotfiles pattern. We somewhat share command patterns via coding streams. Seems doable.
(In general, making it easier to learn new tech and for devs to share / refresh the learning material for a new tech seem underdeveloped.)
If I could add one thing to the list I would include `cib` as equivilent to `ci(` for changing everything in a set of parentheses (or brackets for the mnemonic's sake). For me at least the `b` is easier to reach than the `(`.
I never it existed! It was incredibly helpful with some features I'd never used such as Put, Replace and Visual mode. If you have vim, you should just be able to run `vimtutor` in the command line. If you have trouble, you can run `:help vimtutor` within vim.
Yeah, I've known and used "vi" for a couple of decades, saw someone use visual mode in a video a few months ago, and it blew my mind.
I still don't know how to do project navigation in vi, as I mainly use it for editing config files. I used emacs back in the day, but vscode is what I'm currently most comfortable with for moving between files in a large, deeply nested project.
Use fzf for file navigation and perhaps vim-vinegar. When you open Vim, use :cd to change to your project directory and you’re ready. Use :term to start stuff, e.g., a local web server or whatever. Use fzf to navigate between open buffers.
The "g" namespace is one of the few things I find annoying in Vim (which I like a lot). It is a grabbag of operations at cursor position ("gu", "gU"), mode switches ("gn"), file operations ("gf") and... weird stuff? Like, "ga" (prints the ascii value of the character under the cursor). This really does not help with memorizing the commands.
On the plus side, it enables "* + cgn + ." which is a neat way to do quick multiple substitutions, so yay I guess?
The "g" namespace is a dumping ground for "alternate" versions of things that already have normal-mode mappings.
Personally I think most of the normal mode mappings make no sense, other than the core motions and "q". A lot of precious "one-key" mappings are kind of wasted. You can of course override them, but it feels very "bolted on"
One of my high hopes for Neovim is that eventually they will start migrating the hard-coded default mappings to something more akin to a default config layer, which will be easier to override or disable. They have already started doing this for built-in commands, e.g. :cscope has been removed.
It's on the homerow in the middle of the keyboard, equally accessible to both hands. If it were a symbol key I suspect there would be less perplexity, but because it's a letter key users are left wondering what the mnenomic is :)
Reading the docs and searching into it on a regular basis is the single best advice I could give to Vim users wanting to improve. The odd cheatsheet, the post with a few tricks and cool plugins, all those can be well and good, but nothing beats sitting down and reading the docs. I've been use Vim daily for 10+ years, and I still check help files very regularly. Knowing _how_ to search efficiently is also a skill worth acquiring.
Incidentally, the same advice apply to Bash: just read the man page, and search into it each time it is needed. It is just worth it.
I tried to go through it multiple time, but I couldn't:
1. It's way too long, the complete stuff is ten of thousand of lines.
2. It goes into needless details, especially at the beginning (the "finding help" section is intense for example). It turns me off each time.
3. It's too dry, not really enjoyable to read to me.
I’ve recently switched to Helix editor after 10 years of vim and haven’t looked back. If you’re looking for something a bit simpler, zero configuration, but with the same philosophy as vim (select -> action) give it a try.
What annoyed me with helix was that invisible characters are treated the same as characters. That means your cursor can be positioned after the end of the line, on the '\n' and just sit there.
For instance, if you press "A", you are now after the \n of the end of line, and pressing backspace will remove the \n, joining with the line below.
I tried to ask whether that peculiar behavior could be toggled off somehow, but was welcomed by a wall of extreme purism on how treating differently visible and invisible characters would break the character model of the editor...
I'm too old to entertain the argument, and will just stick back to vim. Maybe its character model is unpure, but at least it's understandable by a mere mortal like me.
There is a pending pull request partially addressing this:
https://github.com/helix-editor/helix/pull/4204
It would be nice to have a comprehensive and convincing explanation in the documentation which sheds lights at the advantages of helix's treating lines. Maybe we vim old timers could learn something new and make a more informed decision about switching to helix.
> with the same philosophy as vim (select -> action)
"select->action" is definitely possible thanks to visual mode but it certainly is not Vim's "philosophy", which would be more in the line of "action->object".
Ha yes, I meant to say opposite philosophy, ugh. Vim is command -> object but Helix it’s the other way around. In Helix you select first then do something.
Zero configuration sounds like the opposite of why I like vim. I want things to work exactly how I want them to work. Vim’s composability of normal, day-to-day actions you already know is its best feature
Im also in the process of switching to Helix and Zellij. I like the minimal configuration of Helix compared to going through multiple git repos just to find the needed neovim config and adjust them to taste.
Holy cow I switch to Helix a couple months ago but its my first time hearing about Zellij and wow this is too powerful with Helix! thank you so much for this!!!!!
A useful Vi/m feature is splitting viewports with Ctrl-w + v/s.
Ctrl-w + v == split current viewport vertically
Ctrl-w + s == split current viewport horizontally
Ctrl-w + = == resize viewports to equal height/widths
You can then move around the viewports with
Ctrl-w + j == move one viewport down from current viewport (if available)
Ctrl-w + k == moves one viewport up from current viewport (if available)
Ctrl-w + h == moves one viewport to the left from current viewport (if available)
Ctrl-w + l == moves one viewport to the right from current viewport (if available)
You can then :q viewports or :e to open a different file in that viewport.
Maybe it's so basic it never gets mentioned but I find a lot of people under utilize it.
Another good one is typing . to repeat previous command. You can do
A, "something"
and then just type `.` to have "something" appended to whatever line the cursor is on.
Thanks for this. I still remind having one of the kindest TAs of my undergrad remark in a thick Ukrainian accent “ahhh, vi, a true master” and move on to helping folks use pico during a *nix programming primer.
(Sometimes ppl would demand I follow the syllabus. I don’t like to follow the guidelines.)
You could always use emacs if you’re into that kind of thing, but telling them you should use pico is like telling them to clean their dorm with equal parts bleach and ammonia soaked in castor beans.
The most annoying thing about vim/vi is that after using it for twenty years I still don't know all the useful things you can do with it. To put that in context, I find vim indispensable. And adding stuff like markdown preview and fzf integration just makes the problem worse. Sigh.
False. The most annoying thing about vim is that I can’t type properly in web input boxes, email clients, rich text editors… I want vim in all the places.
I was doing a live coding challenge in some online editor the other day, and I think they were really confused as to why I kept typing "h" and "k" and "g" all over the place.
I don't care if i'am not using every feature in Vim. I gave up on NVIM, because i was completely done with configuring plugins with bad documentation, no good defaults. For every plugin i needed to learn more and more shortcuts. After an update some plugins were broken etc. I just now stick with VSCode with the NVIM plugin.
This is a good list. I need to get more comfortable with quickfix and location. I’d like to build something like the fzf plug-in some day
I’d highly recommend folks learn some vimscript. Mappings, functions, commands. My most recent use for these was for quickly generating a lot of permalinks for building internal documentation. Macros and argdo are also invaluable for large scale edits.
I recommend using the American keyboard layout if you're doing anything remotely programming related, otherwise all the special characters are just way too annoying (even though personally there's also a few of those in the American layout that are suboptimal, but a keyboard only has so much space...).
If you frequently find yourself needing German (or other European) symbols like ä then you can also look into using EurKEY [1] which is basically the American layout but gives you easy access to the "umlauts".
Have you tried the US-International layout[0]? It's basically the standard QWERTY US layout but ", ', ^ are dead keys used to generate diacritics.
If you press " followed by o you get ö.
' + e prints é.
The only thing to get used to is that if you want quotes for example, you need to press <space> or another character that doesn't accept accents after the key.
I used this layout for French and it's way better than the weird French AZERTY layout.
Meh. I used vim for 20 years. Got to the point of tricking it all out with some of the full-blown ~/.vim configs you can just grab from GitHub. Some of the advanced tips on that site take it into the realm of being emacs. But I found that I was basically trying to get it to be... a GUI, with NERDtree and the lot. When I discovered Sublime Text, and multiple cursors, I quickly gave up on vim. I develop web applications (mostly). I'm pointing and clicking all throughout the process, since web pages are inherently graphical. I still haven't masted all of the keybindings for ST, but I think that being obstinate about keeping my hands on the keyboard when I'm editing is a waste of mental effort. YMMV. I think my lack of being able to fly through editor options without using a mouse cost me a job once, but if a place is going to fetishize that over being a deep expert with 25+ years of experience, go for it. I can solve business problems with software.
* Edited for "Sublime Text," though I don't know why I'm bothering, as this is being downvoted.
I think it's being downvoted because people may be interpreting the opening "meh" as too negative. Or possibly not meeting the standards of Hacker News.
What's the point of leaving a long comment on a post about vim detailing how and why you aren't interested in vim, or about how vim doesn't meet your needs? There are lots of posts here on HN about things that don't interest me, but probably not everyone needs to know about it.
Well, my point was more about how, in the era of GUI's, when working ON GUI's, the idea that vim is somehow miles "better" doesn't necessarily hold up, and measuring how deep your vim knowledge goes is a bit of a nerd dick measuring contest these days, but your point is taken.
> Well, my point was more about how, in the era of GUI's, when working ON GUI's, the idea that vim is somehow miles "better" doesn't necessarily hold up, and measuring how deep your vim knowledge goes is a bit of a nerd dick measuring contest these days, but your point is taken.
But who was making that claim? Yours was a top-level comment, so I can only suppose that it was responding to the article; but I do not find your claim in the article—specifically, I only find two occurrences of the quoted word ‘better’ in the article, neither of which is even mentionining GUIs.
Myself, I have never used any other editor, GUIs included, that matches the experience I have with vim, and I'm a pedestrian user of vim at best. As long as vim keeps existing, it doesn't bother me that other people prefer other experiences; so why inveigh against people with different tastes to yours, or different uses for their text editor from yours, who prefer vim and, preferring it, want to learn how to use it well?
Most advanced guides throw a lot at you at once. Digesting one or few commands at a time works better for me to really make it stick (and that is the goal right?)