12 ms·

Do you find your brain can actually work that way? My issue with all of these relative jump points, repeat this N times, etc of VIM is by the time I’ve calculat

Do you find your brain can actually work that way? My issue with all of these relative jump points, repeat this N times, etc of VIM is by the time I’ve calculated in my mind what the command should be I’d have already done it with just standard navigation/mark/yank/repeat. But perhaps you have galaxy brain ;)

tgb 5y ago
I never use the counts (repeat N times) except for the very simple 55G to go to line 55. It's not useful. But the rest of vim is. I think of it like a chess board. A queen has more moves available than a king. Does that make it harder to move to a certain square with the queen than with the king? Not really, they're both pretty straight forward, if you're not trying to achieve the minimal edit distance to do so. You make big edits when it's obvious and just do smaller edits when it's not. The only commands I have to plan out are search-and-replaces.
SkyMarshal 5y ago
For many commands you’ll only have to make that calculation once, and will remember it going forward. Only commands that are extremely rarely used you may forget and have to reconstruct with the calculation again later.
curriculum 5y ago
No galaxy brain here ;) I generally don't use counts. If I want to go down a few lines, I don't count the number of lines and use 4j or whatever, I instead use / to search for the exact place I want to move to. This feels more natural and preserves the jump-list, so I can ctrl-o back to where I was. Same if I want to delete a few words. I don't count how many I want to delete and do 4daw, instead I do daw and press . until I've deleted everything I want gone. And I make heavy use of text objects when available. If I want to move to the next function, I use the keybinding for that instead of searching or counting lines.
- vulcan01 5y ago
  Instead of counting, you can use :set relativenumber (vim/neovim builtin) to quickly see how far away lines are. (see https://jeffkreeftmeijer.com/vim-number/ https://jeffkreeftmeijer.com/vim-number/)
  - curriculum 5y ago
    In my opinion the real downside of using <count>j and <count>k to move isn't the counting part, it's the fact that <count>k isn't a jump. That means it doesn't go into the jump list.
    - tjdevries 5y ago
      You can do something like this: ``` " Does: " For wrapped lines, does gj/gk " For large jumps, adds a spot on the jump list function! tj#jump_direction(letter) let jump_count = v:count if jump_count == 0 call execute(printf('normal! g%s', a:letter)) return endif if jump_count > 5 call execute("normal! m'") endif call execute(printf('normal! %d%s', jump_count, a:letter)) endfunction ``` and map j and k to this
  - nobleach 5y ago
    I tried to get into that for awhile. I tend to look at the line number where I want to jump, and do <number>gg instead. It has the benefit of allowing me to look at a file and get an idea of what's on lines 400 through 425 (for example).
- bombela 5y ago
  Try the plugin easy motion. It changed my life.
  - Jenk 5y ago
    +1 easy motion makes the default jump-by-search feel really clunky. Typically it is mapped to double-tap leader then object, and it will then highlight those objects with a short-code to jump right to it. Examples: \\w -> will highlight all words after \\b -> all words before \\e -> ends of words after \\ge -> ends of words before \\fe -> all occurences of the char 'e' after \\Fe -> 'e' before \\se -> 'e' in both directions \\j -> lines after \\k -> lines before etc. but can even use it with traditional search: \\n -> will highlight all search-matches found by a previous "/" or "?" search after current pos. \\N -> will highlight all search-matches before. mega useful.
- dundarious 5y ago
  For me, learning about . was what made learning many of (neo)vim’s motions and text objects worthwhile. I use . constantly.
- anon946 5y ago
  I just use a fixed count, like 5j5j5j or whatever to get me close, then jjj or whatever.
  - unrealhoang 5y ago
    I use ctrl + u/d to scroll up and down half screen to get near where I want to go.
konart 5y ago
plugins like https://github.com/phaazon/hop.nvim https://github.com/phaazon/hop.nvim help a lot in cases where it may be hard to tell how to jump to point X
CarelessExpert 5y ago
Keep in mind, even if you don't use motions, text objects, and counts during interactive editing (my own repertoire is pretty limited for the exact reason you mention here), they can be enormously powerful when used with macros.
diegocg 5y ago
The way vim works is actually the opposite of what your brain wants, this is one of the reasons why learning vim tricks is hard. The vim model is "action-object" (eg dw, delete word). A more natural, friendly and interactive model is the opposite, "object-action": first you select the text, your editor highlights the text, then you apply actions to the selection, one by one, and see what happens after each one. Because the text is highlighted beforehand and you see the effect of each action in real time, building chains of commands is much easier and friendly for novices. If you make a mistake, you see its effects and correct it immediately. In vim you have to build the command chain beforehand and calculate in your head what will happen. If you memorize the commands its fine, but if you don't, it's painful. This "object-action" model is used by kakoune (https://kakoune.org/why-kakoune/why-kakoune.html https://kakoune.org/why-kakoune/why-kakoune.html), along with native multicursor support I have found it to be a great alternative after years of not being able to memorize vim commands. Documentation is scarcer at this point, though.
- benhurmarcel 5y ago
  So Kakoune is like RPN (Reverse Polish Notation), and Vim is like Polish Notation then? For sure any user of RPN would agree that it makes more sense to type the operation after the object. Not sure how that translates to modal text editing though.
- oconnor663 5y ago
  I found that over the years, my Vim habits have naturally moved in an "object-action" sort of direction using visual mode. I think a lot of other Vim users end up doing the same. When I tried Kakoune for a few days, I found it difficult to adapt to the differences, but that's probably to be expected no matter what. One thing I particularly missed was g-v ("restore previous visual mode selection"), which I use constantly in Vim. There's a good chance it's doable, though, and I just didn't figure it out.
- chipotle_coyote 5y ago
  You've oddly crystallized why Kakoune has so far failed to grab me! The description you gave of the actions one takes in editing makes sense: in most non-modal editors, you select the text you want to take actions on, then choose the action to take. But, I can do that in literally every modeless editor! That's the way essentially all of them work. But when people write of "Vim as a text editing language" as many comments here do, the action -> object model -- again, at least for me -- fits the pattern. We say "I'm going to the store," not "store I'm going to," unless Yoda we are. And, most programming languages that aren't purely object-oriented tend to follow a rough pattern of "action(parameter)". So in editors like Sublime Text (or VSCode or BBEdit or...) I tend to do editing in an entirely visual way, Vim approaches editing in a more language-based way, and when you describe edits in language, "[verb] the [noun]" is pretty natural.
malwrar 5y ago
Like vim in general it’s not natural, but with practice you slowly start to pick up muscle memory around it. I try to shoot for easy-to-eyeball tricks, a good one is jumping to the place you want to edit with f + the first char. If there’s duplicates in between, you can use ; to go to the next occurrence of the char on that line. There’s plenty of other tricks like that that, in aggregate, makes it feel like you’re talking to your text editor vs leaving home row to click stuff.
- JamesSwift 5y ago
  Exactly. The best approach is layering, in my opinion. Learn the basics, maybe a couple of tricks, and then deliberately add one more thing to your toolbox which would improve your productivity. Then incorporate that new trick into your flow until it sticks, then repeat. Eventually your toolbox is getting full and you are able to recall all the things naturally.
knuthsat 5y ago
Yeah, just recently I had to edit text like this 'name1', 'name2', 'name3', to: 'name1': Enum.Name1, 'name2': Enum.Name2, 'name3': Enum.Name3, by the time I figured out a sequence of keyboard commands I'm pretty sure I could have multicursored it pretty easily, go to name1, create 2 cursors, select word & copy, start typing : Enum., paste selected word, select word, capitalize, type , In vim it was something like qdyi'f,i: Enum.<Esc>pbvlUq and then repeat macro. I found it very slow to even recall. For some reason the multicursor solution feels faster to me most times.
- mpalmer 5y ago
  For me it's been a matter of practice, and forcing myself to use macros for things even when I was too slow with them to justify it in the moment. It pays off eventually and you can get a nice facility with it. I also like using :g/^/norm $normal_commands to apply anonymous macros across all lines. It works with visual selections too: :'<,'>g/^/norm $normal_commands And naturally you can replace the ^ with any regex to selectively apply the macro to only lines that match!
- chousuke 5y ago
  I think I would've used something like :s/'$.*$',/'\1': Enum.\1,/g and then ctrl-v to block-select all the first characters and U to uppercase them. Vi's not always about finding the most efficient way to do something, but having a composable language to do tricks like these comfortably builds up into your own dialect over time.
  - heatmiser 5y ago
    I’m often fallback on the sed match-replace strategy for things like this.
- addicted 5y ago
  Or, you could have hit qt, recorded your commands for the first change, and then replicated it for every other line with a simple @t, instead of redoing all the changes each time. You don't have to learn command. You simply need to know how to edit with VIM. And multi cursors only work for tabular data. The macro recordings can work for the entire document where you call a macro on a word/regex you searched for, for example.
mFixman 5y ago
You could ask the same question to anyone who touch types. Muscle memory is a marvellous thing.
discardable_dan 5y ago
I believe integrating visual mode into your usage flow can help with this a lot.
dkersten 5y ago
I got relatively good at vim N times counting some years back (but forgotten it now as I don't use vim as much these days). It was a practice thing. I made a point to never repeat a command more than twice and after a while it became second nature. I even got really good at guessing how many lines away things were (but nowadays I just use relative line numbers). I never became fully fluent, but I also didn't try too hard over the "don't repeat commands" thing. And I got lazy after about a year (but also used other editors a lot more, due to team members using them and such) and over time lost the ability. Some day perhaps I'll make a point to learn again, but for now I mostly use VSCode without vim mode...
ZeroGravitas 5y ago
I don't use relative jumps or N times repeats, but I do love moving by or dealing with semantic units of things at a time, whether that is a character, w/Word, quoted string, bracket contents, line, paragraph, function, xml tag content etc. and treesitter expands and standardises that across languages, which is nice.
deleted 5y ago
[deleted]
erfgh 5y ago
You can't calculate those commands because you're not meant to calculate them: They are meant for macros and scripting.
crubier 5y ago
Don't worry, you're not alone. 100% of the people I've ever saw using Vim / Neovim spend much longer "calculating" their next command than they would spend just doing in with CMD-D in VSCode. It's frustrating to see. CMD-D in VSCode does 95% of what's needed, with no mental burden. But hey, you can't "brag" that you "know VIM" if you use VSCode...
- nickjj 5y ago
  > 100% of the people I've ever saw using Vim / Neovim spend much longer "calculating" their next command than they would spend just doing in with CMD-D in VSCode. Right, there is mental overhead to calculate moves but often times you can extract out patterns into intuitive key mappings once you've solved the problem once. For example, this is taken my vimrc: nnoremap <silent> s* :let @/='\<'.expand('<cword>').'\>'<CR>cgn xnoremap <silent> s* "sy:let @/=@s<CR>cgn The basic idea here is I can either move the cursor on top of a word or select some text, hit s*, type what I want to change that text to and then hit dot (.) as many times as I want to repeat the change to the next match. It's like being able to use multiple cursors except without needing multiple cursors and I also get to see the result applied once before I start applying it to multiple things. It's also possible to skip matches using existing Vim mappings (n). I use the above all the time to make changes in spots where I would have used multiple cursors with VSCode.
  - crubier 5y ago
    You prove my point. You had to create this insane macro to solve something that cmd-d does automatically in VSCode. And cmd-d is much more versatile, since the same concept applies to many other use cases. And sorry I say insane, but not knowing the language, your macro looks absolutely absurd and as obscure as a sample of brainf*ck. I refuse to learn such a complicated language just to create a macro that replaces cmd-d and cmd-z, just so I can brag that I use Vim.
  - leephillips 5y ago
    Clever! I think I might steal these, or make something based on your idea. Kind of wild: in taking apart your command, I learned three things about Vim that I didn’t know, each one of which is massively useful. And I use it every day!

tgb 5y ago

I never use the counts (repeat N times) except for the very simple 55G to go to line 55. It's not useful. But the rest of vim is. I think of it like a chess board. A queen has more moves available than a king. Does that make it harder to move to a certain square with the queen than with the king? Not really, they're both pretty straight forward, if you're not trying to achieve the minimal edit distance to do so. You make big edits when it's obvious and just do smaller edits when it's not. The only commands I have to plan out are search-and-replaces.

SkyMarshal 5y ago

For many commands you’ll only have to make that calculation once, and will remember it going forward. Only commands that are extremely rarely used you may forget and have to reconstruct with the calculation again later.

curriculum 5y ago

No galaxy brain here ;) I generally don't use counts. If I want to go down a few lines, I don't count the number of lines and use 4j or whatever, I instead use / to search for the exact place I want to move to. This feels more natural and preserves the jump-list, so I can ctrl-o back to where I was. Same if I want to delete a few words. I don't count how many I want to delete and do 4daw, instead I do daw and press . until I've deleted everything I want gone. And I make heavy use of text objects when available. If I want to move to the next function, I use the keybinding for that instead of searching or counting lines.

vulcan01 5y ago
Instead of counting, you can use :set relativenumber (vim/neovim builtin) to quickly see how far away lines are. (see https://jeffkreeftmeijer.com/vim-number/ https://jeffkreeftmeijer.com/vim-number/)
- curriculum 5y ago
  In my opinion the real downside of using <count>j and <count>k to move isn't the counting part, it's the fact that <count>k isn't a jump. That means it doesn't go into the jump list.
  - tjdevries 5y ago
    You can do something like this: ``` " Does: " For wrapped lines, does gj/gk " For large jumps, adds a spot on the jump list function! tj#jump_direction(letter) let jump_count = v:count if jump_count == 0 call execute(printf('normal! g%s', a:letter)) return endif if jump_count > 5 call execute("normal! m'") endif call execute(printf('normal! %d%s', jump_count, a:letter)) endfunction ``` and map j and k to this
- nobleach 5y ago
  I tried to get into that for awhile. I tend to look at the line number where I want to jump, and do <number>gg instead. It has the benefit of allowing me to look at a file and get an idea of what's on lines 400 through 425 (for example).
bombela 5y ago
Try the plugin easy motion. It changed my life.
- Jenk 5y ago
  +1 easy motion makes the default jump-by-search feel really clunky. Typically it is mapped to double-tap leader then object, and it will then highlight those objects with a short-code to jump right to it. Examples: \\w -> will highlight all words after \\b -> all words before \\e -> ends of words after \\ge -> ends of words before \\fe -> all occurences of the char 'e' after \\Fe -> 'e' before \\se -> 'e' in both directions \\j -> lines after \\k -> lines before etc. but can even use it with traditional search: \\n -> will highlight all search-matches found by a previous "/" or "?" search after current pos. \\N -> will highlight all search-matches before. mega useful.
dundarious 5y ago
For me, learning about . was what made learning many of (neo)vim’s motions and text objects worthwhile. I use . constantly.
anon946 5y ago
I just use a fixed count, like 5j5j5j or whatever to get me close, then jjj or whatever.
- unrealhoang 5y ago
  I use ctrl + u/d to scroll up and down half screen to get near where I want to go.

konart 5y ago

plugins like https://github.com/phaazon/hop.nvim https://github.com/phaazon/hop.nvim help a lot in cases where it may be hard to tell how to jump to point X

CarelessExpert 5y ago

Keep in mind, even if you don't use motions, text objects, and counts during interactive editing (my own repertoire is pretty limited for the exact reason you mention here), they can be enormously powerful when used with macros.

diegocg 5y ago

The way vim works is actually the opposite of what your brain wants, this is one of the reasons why learning vim tricks is hard. The vim model is "action-object" (eg dw, delete word). A more natural, friendly and interactive model is the opposite, "object-action": first you select the text, your editor highlights the text, then you apply actions to the selection, one by one, and see what happens after each one. Because the text is highlighted beforehand and you see the effect of each action in real time, building chains of commands is much easier and friendly for novices. If you make a mistake, you see its effects and correct it immediately. In vim you have to build the command chain beforehand and calculate in your head what will happen. If you memorize the commands its fine, but if you don't, it's painful. This "object-action" model is used by kakoune (https://kakoune.org/why-kakoune/why-kakoune.html https://kakoune.org/why-kakoune/why-kakoune.html), along with native multicursor support I have found it to be a great alternative after years of not being able to memorize vim commands. Documentation is scarcer at this point, though.

benhurmarcel 5y ago
So Kakoune is like RPN (Reverse Polish Notation), and Vim is like Polish Notation then? For sure any user of RPN would agree that it makes more sense to type the operation after the object. Not sure how that translates to modal text editing though.
oconnor663 5y ago
I found that over the years, my Vim habits have naturally moved in an "object-action" sort of direction using visual mode. I think a lot of other Vim users end up doing the same. When I tried Kakoune for a few days, I found it difficult to adapt to the differences, but that's probably to be expected no matter what. One thing I particularly missed was g-v ("restore previous visual mode selection"), which I use constantly in Vim. There's a good chance it's doable, though, and I just didn't figure it out.
chipotle_coyote 5y ago
You've oddly crystallized why Kakoune has so far failed to grab me! The description you gave of the actions one takes in editing makes sense: in most non-modal editors, you select the text you want to take actions on, then choose the action to take. But, I can do that in literally every modeless editor! That's the way essentially all of them work. But when people write of "Vim as a text editing language" as many comments here do, the action -> object model -- again, at least for me -- fits the pattern. We say "I'm going to the store," not "store I'm going to," unless Yoda we are. And, most programming languages that aren't purely object-oriented tend to follow a rough pattern of "action(parameter)". So in editors like Sublime Text (or VSCode or BBEdit or...) I tend to do editing in an entirely visual way, Vim approaches editing in a more language-based way, and when you describe edits in language, "[verb] the [noun]" is pretty natural.

malwrar 5y ago

Like vim in general it’s not natural, but with practice you slowly start to pick up muscle memory around it. I try to shoot for easy-to-eyeball tricks, a good one is jumping to the place you want to edit with f + the first char. If there’s duplicates in between, you can use ; to go to the next occurrence of the char on that line. There’s plenty of other tricks like that that, in aggregate, makes it feel like you’re talking to your text editor vs leaving home row to click stuff.

JamesSwift 5y ago
Exactly. The best approach is layering, in my opinion. Learn the basics, maybe a couple of tricks, and then deliberately add one more thing to your toolbox which would improve your productivity. Then incorporate that new trick into your flow until it sticks, then repeat. Eventually your toolbox is getting full and you are able to recall all the things naturally.

knuthsat 5y ago

Yeah, just recently I had to edit text like this 'name1', 'name2', 'name3', to: 'name1': Enum.Name1, 'name2': Enum.Name2, 'name3': Enum.Name3, by the time I figured out a sequence of keyboard commands I'm pretty sure I could have multicursored it pretty easily, go to name1, create 2 cursors, select word & copy, start typing : Enum., paste selected word, select word, capitalize, type , In vim it was something like qdyi'f,i: Enum.<Esc>pbvlUq and then repeat macro. I found it very slow to even recall. For some reason the multicursor solution feels faster to me most times.

mpalmer 5y ago
For me it's been a matter of practice, and forcing myself to use macros for things even when I was too slow with them to justify it in the moment. It pays off eventually and you can get a nice facility with it. I also like using :g/^/norm $normal_commands to apply anonymous macros across all lines. It works with visual selections too: :'<,'>g/^/norm $normal_commands And naturally you can replace the ^ with any regex to selectively apply the macro to only lines that match!
chousuke 5y ago
I think I would've used something like :s/'$.*$',/'\1': Enum.\1,/g and then ctrl-v to block-select all the first characters and U to uppercase them. Vi's not always about finding the most efficient way to do something, but having a composable language to do tricks like these comfortably builds up into your own dialect over time.
- heatmiser 5y ago
  I’m often fallback on the sed match-replace strategy for things like this.
addicted 5y ago
Or, you could have hit qt, recorded your commands for the first change, and then replicated it for every other line with a simple @t, instead of redoing all the changes each time. You don't have to learn command. You simply need to know how to edit with VIM. And multi cursors only work for tabular data. The macro recordings can work for the entire document where you call a macro on a word/regex you searched for, for example.

mFixman 5y ago

You could ask the same question to anyone who touch types. Muscle memory is a marvellous thing.

discardable_dan 5y ago

I believe integrating visual mode into your usage flow can help with this a lot.

dkersten 5y ago

I got relatively good at vim N times counting some years back (but forgotten it now as I don't use vim as much these days). It was a practice thing. I made a point to never repeat a command more than twice and after a while it became second nature. I even got really good at guessing how many lines away things were (but nowadays I just use relative line numbers). I never became fully fluent, but I also didn't try too hard over the "don't repeat commands" thing. And I got lazy after about a year (but also used other editors a lot more, due to team members using them and such) and over time lost the ability. Some day perhaps I'll make a point to learn again, but for now I mostly use VSCode without vim mode...

ZeroGravitas 5y ago

I don't use relative jumps or N times repeats, but I do love moving by or dealing with semantic units of things at a time, whether that is a character, w/Word, quoted string, bracket contents, line, paragraph, function, xml tag content etc. and treesitter expands and standardises that across languages, which is nice.

deleted 5y ago

[deleted]

erfgh 5y ago

You can't calculate those commands because you're not meant to calculate them: They are meant for macros and scripting.

crubier 5y ago

Don't worry, you're not alone. 100% of the people I've ever saw using Vim / Neovim spend much longer "calculating" their next command than they would spend just doing in with CMD-D in VSCode. It's frustrating to see. CMD-D in VSCode does 95% of what's needed, with no mental burden. But hey, you can't "brag" that you "know VIM" if you use VSCode...

nickjj 5y ago
> 100% of the people I've ever saw using Vim / Neovim spend much longer "calculating" their next command than they would spend just doing in with CMD-D in VSCode. Right, there is mental overhead to calculate moves but often times you can extract out patterns into intuitive key mappings once you've solved the problem once. For example, this is taken my vimrc: nnoremap <silent> s* :let @/='\<'.expand('<cword>').'\>'<CR>cgn xnoremap <silent> s* "sy:let @/=@s<CR>cgn The basic idea here is I can either move the cursor on top of a word or select some text, hit s*, type what I want to change that text to and then hit dot (.) as many times as I want to repeat the change to the next match. It's like being able to use multiple cursors except without needing multiple cursors and I also get to see the result applied once before I start applying it to multiple things. It's also possible to skip matches using existing Vim mappings (n). I use the above all the time to make changes in spots where I would have used multiple cursors with VSCode.
- crubier 5y ago
  You prove my point. You had to create this insane macro to solve something that cmd-d does automatically in VSCode. And cmd-d is much more versatile, since the same concept applies to many other use cases. And sorry I say insane, but not knowing the language, your macro looks absolutely absurd and as obscure as a sample of brainf*ck. I refuse to learn such a complicated language just to create a macro that replaces cmd-d and cmd-z, just so I can brag that I use Vim.
- leephillips 5y ago
  Clever! I think I might steal these, or make something based on your idea. Kind of wild: in taking apart your command, I learned three things about Vim that I didn’t know, each one of which is massively useful. And I use it every day!