4 ms·
I agree, the "5dd" example is super contrived, though not as much as you think. In vim, you can have the line numbers on the left show you numbers relative to y
by phailhaus 5y ago
I agree, the "5dd" example is super contrived, though not as much as you think. In vim, you can have the line numbers on the left show you numbers relative to your current line, so you never really have to count, you can just look at the number on the line you want to go to.
But outside of that, the problem with standard editors is that none of your keyboard shortcuts compose together. You have special shortcuts for deleting lines vs deleting individual words. No shortcut for copying objects to your clipboard. No shortcuts for "get me what's within these parens". You can't move between panes with consistent keybindings, because most editors represent code panes vs directory panes differently.
Vim lets you think of editing and navigating your code in terms of verbs and objects, and treats everything consistently. Take the "w" object, that's "word". Now I can move around by word by mashing "w", I can delete with "dw", change with "cw", yank to clipboard with "yw". The "." command lets me repeat, so I can do things like "dw..." and delete more easily. Some plugins add more objects, like being able to refer to surrounded text (e.g., in parentheses.) They compose with all the verbs you already know, so now I can delete inside parens, surround with parens, replace text within parens, copy in parens, etc.
Vim compared to standard text editors is like functional vs imperative programming. It works best for code, because editing code is not like writing prose. You're manipulating a syntax tree.
- crubier 5y agoThank you for this explanation. It makes sense. But still, I find that vim is overcomplicating things for no good reason. What happened to KISS? Like every time I make this sort of remark, the thread becomes a thread about vim people debating that actually typing dd multiple time is better, or that dk could do the trick, or that select text followed by d is better, or that d% does the trick, or soon someone will share their custom shortcut that address this particular case, etc. Vim people have to think about Vim way too much. Meanwhile, keyboard shortcuts on a Mac do compose: arrow=Move, shift-arrow=Select, arrow=a character at a time (or vertically, a line), shift-arrow=a word at a time (or vertically a paragraph) cmd-arrow=the whole line (or vertically the whole file). Also cmd-d has immense powers when you know how to use it. And finally let me mention that syntax-aware editing is overrated when you use a linter/formatter because regular indentation and normal shortcuts work flawlessly already. Last but not least: these shortcuts work system wide! So we don’t have to reimplement every possible software within my text editor so I can use these shortcuts.
- phailhaus 5y agoIt's not like you _need_ vim to edit code. If those are the only shortcuts you need, then you don't need vim! It's just very useful for power users, especially with the huge plugin ecosystem. Instead of each plugin adding its own shortcuts, they often compose together with what you already know to make editing even easier. > syntax-aware editing is overrated when you use a linter/formatter Not quite what I'm talking about actually. Going back to the theme of "code as syntax tree", when editing code you'll often find yourself needing to do things like "ah I should hoist the code in this paren block into its own variable." Vim lets me operate on that syntax level, which feels more reliable to me than using the mouse to carefully select text. I just tell it to delete in parens (which automatically pulls it into a register that I can paste from), move to a new line, paste with "p". When I edit code it's less about individual characters and more about moving blocks of logic around, which is super important for refactoring safely. I end up making fewer mistakes with vim.