10 ms·

We've got younger guys on my team that hem and haw about the fact that we only have vim on our hardware implementation (SAMA5 busy box), and straight up don't u

by auto 3y ago

We've got younger guys on my team that hem and haw about the fact that we only have vim on our hardware implementation (SAMA5 busy box), and straight up don't understand why I basically can't use VSCode without the extension, and this article hits on so many good points. Vim is extremely expressive, and everyone ends up using it in slightly different ways. For me, my movement tends to center around: - 'e' and 'k' rapidly, or 'h' and 'b' rapidly to move left and right, or using 'f'/'F' and a target character, with '0' and '$' as needed - For vertical movement, I tend to use ctrl+'d'/'u' to move the document up and down in chunks, then specific line numbers, as well as marks (usually at most 2-3, with 'a', 'b', and 'c') to hold on to specific areas, or I just end up remembering line numbers and jumping to them. - Lots of yanking and deleting to specific targets, be it hori or vert There's plenty more beyond that, but that really is the "crux" of my vim usage, and from what I've seen watching over the shoulders of many programmers over the years, it makes me way faster than most. Programming isn't about typing speed, but my work is often in doing large refactors in enormous codebases. I need to be able to move around as close to the speed of thought as possible, and I have never found a tool that comes anywhere close to providing that ability as vim. Also, any chance I get to plug the greatest StackExchange answer ever, I will: https://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118 https://stackoverflow.com/questions/1218390/what-is-your-mos...

yodsanklai 3y ago
My usage is similar. I also use all the time - shift - v - } to select a block, or v - w to select a word. It's not strictly needed but help ensure selecting the right stuff - ctrl i - ctrl o for navigation I've never been able to use tabs, buffers, multiple file edition, that's just too much overhead for me. I rely on vscode for that. That being said, I don't think using vim gives me a competitive advantage. I'm also rather proficient using standard OS shortcut. I like vim out of laziness, it minimizes hand motion, but don't make that big of a difference IMHO. (also lots of young guys use vim too, some younger guys in my team even refuse to use vscode...) EDIT: also vi adds a lot of value in the terminal where standard OS shortcuts don't work, at least on MacOS (i'm waiting for comments telling me how to make them work!)
- hannofcart 3y ago
  You can just use nvim _as_ the terminal itself: nvim +startinsert -u $HOME/.i3/terminal.init.vim term://bash A post with more customizations: https://www.balajeerc.info/My-New-Favourite-Terminal-Emulator-Vim/ https://www.balajeerc.info/My-New-Favourite-Terminal-Emulato...
adhoc_slime 3y ago
Wow that SO post is really good, I'm 100% keeping it in my tool belt for dropping niche articles on unsuspecting co-workers. Thanks for sharing.
vram22 3y ago
"Your problem with vim is that you do not grok vi". Yes, that StackOverflow answer (which starts with the above line) is one of the best I have ever read, on any subject, not just vim. (However, I should mention that I have not read, say, thousands of stack overflow answers, only in the range of hundreds, because I was never a heavy StackOverflow or StackExchange user.) Anyway, FWIW, I think that answer could described as partly explaining the "Zen" of vi(m). And for people who are intrigued by the benefits of vi(m) mentioned by various commenters in this thread, and would like to start using it, I have a small vi tutorial, which is applicable to vim too. Those new to vi(m), check this vi quickstart tutorial that I created. https://gumroad.com/l/vi_quick https://gumroad.com/l/vi_quick From the start of a Twitter subthread I wrote about the tutorial (thread unfortunately deleted later by accident - Twitter should have an undo feature like vim, heh): [ Those new to vi / vim, hit the ground running with my short vi quickstart tutorial here: https://gumroad.com/l/vi_quick https://gumroad.com/l/vi_quick I first wrote that tutorial at the request of a couple of Windows system admin friends of mine (at a company where I worked earlier), who were tasked with managing a few Unix boxes, without knowing Unix. They used the tutorial and later told me that it helped them to quickly start using vi to do their work on those boxes, including editing config files, simple shell scripts, etc. Edit: Since vi is mostly a subset of vim, the tutorial works for vim too. ]
weaksauce 3y ago
vscode with the neovim extension is awesome... almost perfect.
- mcluck 3y ago
  I've asked this before but I'll ask it again. Usually when people say they don't like vim plugins for other editors, they say that the plugin doesn't do everything they need. What features of vim are people missing in the plugins? I've been using vim and vim bindings for like 3 years now. I've occasionally ran in to something that the plugin doesn't handle well but I can work around it with a custom binding. This has only happened a handful of times. I'm genuinely curious about what features of vim I've been missing out on!
  - stnmtn 3y ago
    IME, these people just haven't put as much effort into it as they've put into their custom VIM/emacs configs. There might also be a sunk cost fallacy aspect to it as well But there's nothing in VIM that I'm not able to do in VSCode. Especially when you realize you can very very easily bind VSCode commands to keys in VIM. It starts to feel like a superpower.
    - weaksauce 3y ago
      you can do that in the neovim vscode extension too though and everything else is faster in spades. from my neovim config: nnoremap <silent> zc <Cmd>call VSCodeNotify('editor.fold')<CR> nnoremap <silent> zo <Cmd>call VSCodeNotify('editor.unfold')<CR>
  - xigoi 3y ago
    > What features of vim are people missing in the plugins? The feature of not having your editor made by an evil greedy corporation. Oh, and also startup time and memory usage.
  - weaksauce 3y ago
    it’s literally neovim in normal mode but when in insert mode it’s vscode basically. there’s weird edge cases when you try to replicate all of vim’s features without it being actual vim. it’s faster too. it can use almost any neovim plugin too as it’s, again, actually neovim doing the hard work.
b33j0r 3y ago
I just really find visual debuggers to be a modern miracle. I’m a veteran, but I run into that every time. I use nvim and pycharm. Are there new developments that could change my mind? I love the idea of all of this.
- ziftface 3y ago
  I've had great luck with nvim-dap and nvim-dap-ui.
- Foxboron 3y ago
  vimspector is a cool DSP for vim. https://github.com/puremourning/vimspector/ https://github.com/puremourning/vimspector/
- weaksauce 3y ago
  use vscode with the neovim plugin. it has visual debugging built in and you can bind whatever command in vscode to a command in neovim if you want.
- llimllib 3y ago
  I only use vim for editing, but I reach for Chrome or VS Code for my debugging - I don't love the UI, but I don't do it that often and it's fine enough
  - sva_ 3y ago
    > I reach for Chrome Did you check the Vimium extension for Chrome? https://chrome.google.com/webstore/detail/vimium/dbepggeogbaibhgnhhndojpepiihcmeb https://chrome.google.com/webstore/detail/vimium/dbepggeogba...
    - llimllib 3y ago
      lol, here's me 13 years ago on that repo filing an issue about google reader support (!) https://github.com/philc/vimium/issues/82 https://github.com/philc/vimium/issues/82 anyway, yeah I'm aware of it haha edit: my fork is still alive! Here's a commit from 2011 that I never filed a PR for that includes a news.yc submission keyboard shortcut for vimium: https://github.com/llimllib/vimium/commit/59e3d7f7aa01bb032d53bdbe55671e46b1bfa67f https://github.com/llimllib/vimium/commit/59e3d7f7aa01bb032d...
cassepipe 3y ago
All of that but now I rely even more on searching a few characters to move around and do a lot of edit I make with :<,>s//g or :%s//g with the plugin that shows the result in realtime called traces. Vim regex is not the best and there's an option to change but I got used to it. Recommend http://www.vimregex.com/ http://www.vimregex.com/ gv is quite handy when you want to reselect last to rerun a command on it too
sublinear 3y ago
I don't have a problem using both in their more or less default configuration. I use vscode for editing code without any special keybinds and just a couple of plugins for syntax highlighting. I use vim for everything else in the terminal window (also without plugins). I don't experience any speed difference or difficulty switching between the two. Yeah I'm going to say something blasphemous... they're about the same. Vim is just slightly jankier, but more mature/capable.
taf2 3y ago
Moving text is great in vim but being embedded in the terminal means all the powers of the shell are one ! away as well that makes it faster to do things… need a quick syntax check !node -c % , or need to run a command !ruby % It’s just faster when you are connected shell… and unlike vscode - vim is pushing 30 and the shell environment 40, I see very little reason the shell and vim will substantially change in the next 40 years… but I guarantee vscode will look very different… so learn a tool for life that will be just as powerful tomorrow as it is today
- AdieuToLogic 3y ago
  > Moving text is great in vim but being embedded in the terminal means all the powers of the shell are one ! away as well that makes it faster to do things… Quite true. Also, partial buffer manipulation can be done with external programs via range constraints. For example, to reverse sort only the first 5 lines of in buffer, one can execute this ex[0] command: :1,5 !sort -r 0 - https://man.freebsd.org/cgi/man.cgi?query=ex&apropos=0&sektion=0&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=ex&apropos=0&sekti...
  - schoen 3y ago
    I like to use vi as a kind of IDE for shell commands, because you can, for example, !}somecommand to pipe a paragraph through that command, or 1G!Gsomecommand to pipe the whole editing buffer through that command, which is also equivalent to :1,$!somecommand which I find less obvious as a way to do that, even though it makes sense historically in terms of ed and ex. You can also, in vim, use u and ^R to undo your pipe transformation and redo it, so you're basically then doing a series of shell pipe transformations with interactive history. If you need to generate text with a shell command instead of pipe existing text through it, you can use :r!somecommand Commands that I like to use in this context include tac, rev, tr, cut, grep, and sed (although using sed this way is a little silly since the substitutions I'm doing are normally also available natively inside of vi itself). A simple example that I like a lot is 1G!Ggrep . which removes all empty lines from the current file. ("Line 1 go to line, pipe from here to result of movement go to end of file, command 'grep .' [print lines that match 'any character']") The classic ed/ex way to do this is :1,$g/^$/d which is just as many characters, but which requires lots of explicit thought for me, while the "1G!G grep ." version seems to no longer require explicit thought at all. ("For lines 1 to last line, repeatedly match ^$ [line beginning immediately followed by line end], delete matching lines.")
q7xvh97o2pDhNrh 3y ago
Wow, this is fascinating to hear. Other than the standard baseline of not touching the arrow keys, I use vim pretty differently: - 'j' and 'k' to move up and down, with '{' or '}' or even something like '20j' to move quickly - 'w' and '$' and '0' to move horizontally, with things like '5w' to move quickly I also rely heavily on 'v' and ctrl+'v' to select arbitrary shapes of text for yanking/deleting. I'm not sure what the exact takeaway is from comparing our styles, but it's interesting to realize about how much of coding comes down to just navigating up/down/left/right. I agree with your last couple paragraphs almost verbatim though! That StackOverflow answer is exactly the reason I decided to try vim and stuck with it. The verb/noun nature of vim makes it so easy to enter a flow state. The text editor fades into muscle memory, and you can surf waves of code with no bottleneck between mind and machine. (To write this comment, I actually had to open a random file and navigate around it while watching my hands — it's been years since I've thought about it!)
- jrumbut 3y ago
  I might be a perfect complement to the grandparent. I use w b $ and ^ to move horizontally. I like using w and b because then I can hit cw to make a small change. For vertical (I don't really think in terms of horizontal and vertical, I think about it as a streams of "words" and "spaces") I usually do a search (/ or ? to go up or down) or for some files I do 20j like you. Shamefully, I do sometimes use the mouse out of habit from other programs. I can't remember the last time I used f.
  - dfinninger 3y ago
    I usually go for “ciw“ to make changes from wherever I am in the word. It lets me use w or e because I’m not usually paying attention to which one I’m smashing. :)
  - bottlero_cket 3y ago
    f I use second most. It has so many uses all of which could be done with / command, but definitely you come to prefer f. I use f( to scan forward to the next open paren. Then I use di( to delete in parens for example to remove the arguments. Uppercase F does the same but backward up the text. Often I use f, to go to a comma. df, to delete up to the next comma as in removing just 1 argument. The only draw back is that f does not have any repeat shortcut like n for next or . for reapply, those do nothing for f. I should mention also that f works on a single line at a time unlike /
galkk 3y ago
I kind of settled on vim as console editor in Linux but it will never replace good ide for me, and modern ides are getting/having vim mode for navigation, making then even more compelling. * Do you want autodetect indent and tab rule in file? Install plugin. * Do you want to automatically insert matching closing parenthesis - rebind keys (half baked solution) or plugin. * Vertical scrollbar? Plugin * Autocomplete code using lsp? Dance with plugins or copy paste literal screens of configs for nvim * Want nice looking theme? Plugin! (Gruvbox in my case) * Install and manage plugins? 3rd party Plugin for that too, with init code that will clone it itself from GitHub * Wrap long lines by whole words if possible? No default setting, I guess I need to search for plugin for that too. List goes on and on, and it is just I’m looking at my vimrc and recalling why I added or another thing. And there are many things which I decided to just to not care about, because it requires too much time to get it work Parent mentioned refactorings, but trust me, no matter what typing/navigating speed is, the standard refactorings in modern ides (that I bet cover most of typical refactoring work) will work faster and more correctly than manually doing the same. Even basic things like projectwise method rename or extracting something to parameter. Almost every quality of life improvement that is standard in modern ides require tinkering with vim.
- wruza 3y ago
  That’s mostly true, but then one day you want to use an external filter, or a custom set of snippets that doesn’t suck at editing them, or make the next line align correctly after “(“ and there’s no plugin for that in your ide. And, more importantly, it’s a pita to create and publish one. It’s not better or worse, some people like off the shelf availability, some like local fine tuning. Would be nice to have a full union, but ides suck at local customization that wasn’t trivial or planned in advance. Added: I hate both worlds now. Where’s an editor that is full of modern features and at the same time easily programmable?
  - pcblues 3y ago
    The last great effort with resources, experts, etc. was VSCode. If they can't nail it, can it be done?
eviks 3y ago
The greatest SO answer ignores the core issue "But you never know exactly if you've selected what you wanted." The solution to this is switching verb-object to object-verb like kakoune/helix do, but I guess that goes too much against the "zen of vim"
- nsvd 3y ago
  Why not just use visual mode to see what you're selecting?
  - eviks 3y ago
    VISUAL always extends and clears selection on mode switching, so it doesn't fit. It's a bit challenging to explain in a brief comment, so maybe check "Improving on the editing model" section https://kakoune.org/why-kakoune/why-kakoune.html#_why_kakoune https://kakoune.org/why-kakoune/why-kakoune.html#_why_kakoun...
- xigoi 3y ago
  My problem with object-verb is that it requires much more keymaps for motions (you need to distinguish between “move selection” and “extend selection”).
  - eviks 3y ago
    Extend selection is via the same select mode that vim already has, so that's 1 extra key prefix, and move selection is enabled by default, so regular move commands pre-select what they move over, so in some cases that's even saving you a keypress :) Though it's not that it should be the only way to go (plenty of vim pros have adjusted), it's just visual feedback is very powerful, and lack thereof is a legitimate big challenge you shouldn't ignore in the "greatest" answer
    - drbaba 3y ago
      I wonder how it would be if one attempted to make Vim’s verb-object system more visual instead? Imagine if say “dwww” would highlight the next three words in red to mark them for deletion - but until you press enter to execute the deletion, you remain in a visual-like mode where you can adjust the region you want to delete by pressing more motion keys. Similarly, pressing “yip}” could highlight two paragraph (in paragraph + next paragraph) in yellow and then yank them when you press enter. This would kinda be the opposite of the idea in Helix/Kakoune: one automatically enters a visual-mode-like state after typing a verb that expects an object.
gigatexal 3y ago
Kids these days and their addiction to electron smh ;) I think I’m only scratching the service with my neovim setup. But besides the plugins that make it a bit more like a full IDE I’m using some set of core commands, heavy use of visual selection and s/foo/bar etc. I learned a lot from this guide. I didn’t know about the f and t commands. Very cool.
hashar 3y ago
> Also, any chance I get to plug the greatest StackExchange answer ever, I will: https://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118 https://stackoverflow.com/questions/1218390/what-is-your-mos... You might consider posting that link a standalone entry on hacker news. That was a very great read well worth additional exposure. > "cdd" "@c" is effectively a finger macro for me That is pretty much how I use vi: muscle memory :]

by auto 3y ago

yodsanklai 3y ago

My usage is similar. I also use all the time - shift - v - } to select a block, or v - w to select a word. It's not strictly needed but help ensure selecting the right stuff - ctrl i - ctrl o for navigation I've never been able to use tabs, buffers, multiple file edition, that's just too much overhead for me. I rely on vscode for that. That being said, I don't think using vim gives me a competitive advantage. I'm also rather proficient using standard OS shortcut. I like vim out of laziness, it minimizes hand motion, but don't make that big of a difference IMHO. (also lots of young guys use vim too, some younger guys in my team even refuse to use vscode...) EDIT: also vi adds a lot of value in the terminal where standard OS shortcuts don't work, at least on MacOS (i'm waiting for comments telling me how to make them work!)

hannofcart 3y ago
You can just use nvim _as_ the terminal itself: nvim +startinsert -u $HOME/.i3/terminal.init.vim term://bash A post with more customizations: https://www.balajeerc.info/My-New-Favourite-Terminal-Emulator-Vim/ https://www.balajeerc.info/My-New-Favourite-Terminal-Emulato...

adhoc_slime 3y ago

Wow that SO post is really good, I'm 100% keeping it in my tool belt for dropping niche articles on unsuspecting co-workers. Thanks for sharing.

vram22 3y ago

"Your problem with vim is that you do not grok vi". Yes, that StackOverflow answer (which starts with the above line) is one of the best I have ever read, on any subject, not just vim. (However, I should mention that I have not read, say, thousands of stack overflow answers, only in the range of hundreds, because I was never a heavy StackOverflow or StackExchange user.) Anyway, FWIW, I think that answer could described as partly explaining the "Zen" of vi(m). And for people who are intrigued by the benefits of vi(m) mentioned by various commenters in this thread, and would like to start using it, I have a small vi tutorial, which is applicable to vim too. Those new to vi(m), check this vi quickstart tutorial that I created. https://gumroad.com/l/vi_quick https://gumroad.com/l/vi_quick From the start of a Twitter subthread I wrote about the tutorial (thread unfortunately deleted later by accident - Twitter should have an undo feature like vim, heh): [ Those new to vi / vim, hit the ground running with my short vi quickstart tutorial here: https://gumroad.com/l/vi_quick https://gumroad.com/l/vi_quick I first wrote that tutorial at the request of a couple of Windows system admin friends of mine (at a company where I worked earlier), who were tasked with managing a few Unix boxes, without knowing Unix. They used the tutorial and later told me that it helped them to quickly start using vi to do their work on those boxes, including editing config files, simple shell scripts, etc. Edit: Since vi is mostly a subset of vim, the tutorial works for vim too. ]

weaksauce 3y ago

vscode with the neovim extension is awesome... almost perfect.

mcluck 3y ago
I've asked this before but I'll ask it again. Usually when people say they don't like vim plugins for other editors, they say that the plugin doesn't do everything they need. What features of vim are people missing in the plugins? I've been using vim and vim bindings for like 3 years now. I've occasionally ran in to something that the plugin doesn't handle well but I can work around it with a custom binding. This has only happened a handful of times. I'm genuinely curious about what features of vim I've been missing out on!
- stnmtn 3y ago
  IME, these people just haven't put as much effort into it as they've put into their custom VIM/emacs configs. There might also be a sunk cost fallacy aspect to it as well But there's nothing in VIM that I'm not able to do in VSCode. Especially when you realize you can very very easily bind VSCode commands to keys in VIM. It starts to feel like a superpower.
  - weaksauce 3y ago
    you can do that in the neovim vscode extension too though and everything else is faster in spades. from my neovim config: nnoremap <silent> zc <Cmd>call VSCodeNotify('editor.fold')<CR> nnoremap <silent> zo <Cmd>call VSCodeNotify('editor.unfold')<CR>
- xigoi 3y ago
  > What features of vim are people missing in the plugins? The feature of not having your editor made by an evil greedy corporation. Oh, and also startup time and memory usage.
- weaksauce 3y ago
  it’s literally neovim in normal mode but when in insert mode it’s vscode basically. there’s weird edge cases when you try to replicate all of vim’s features without it being actual vim. it’s faster too. it can use almost any neovim plugin too as it’s, again, actually neovim doing the hard work.

b33j0r 3y ago

I just really find visual debuggers to be a modern miracle. I’m a veteran, but I run into that every time. I use nvim and pycharm. Are there new developments that could change my mind? I love the idea of all of this.

ziftface 3y ago
I've had great luck with nvim-dap and nvim-dap-ui.
Foxboron 3y ago
vimspector is a cool DSP for vim. https://github.com/puremourning/vimspector/ https://github.com/puremourning/vimspector/
weaksauce 3y ago
use vscode with the neovim plugin. it has visual debugging built in and you can bind whatever command in vscode to a command in neovim if you want.
llimllib 3y ago
I only use vim for editing, but I reach for Chrome or VS Code for my debugging - I don't love the UI, but I don't do it that often and it's fine enough
- sva_ 3y ago
  > I reach for Chrome Did you check the Vimium extension for Chrome? https://chrome.google.com/webstore/detail/vimium/dbepggeogbaibhgnhhndojpepiihcmeb https://chrome.google.com/webstore/detail/vimium/dbepggeogba...
  - llimllib 3y ago
    lol, here's me 13 years ago on that repo filing an issue about google reader support (!) https://github.com/philc/vimium/issues/82 https://github.com/philc/vimium/issues/82 anyway, yeah I'm aware of it haha edit: my fork is still alive! Here's a commit from 2011 that I never filed a PR for that includes a news.yc submission keyboard shortcut for vimium: https://github.com/llimllib/vimium/commit/59e3d7f7aa01bb032d53bdbe55671e46b1bfa67f https://github.com/llimllib/vimium/commit/59e3d7f7aa01bb032d...

cassepipe 3y ago

All of that but now I rely even more on searching a few characters to move around and do a lot of edit I make with :<,>s//g or :%s//g with the plugin that shows the result in realtime called traces. Vim regex is not the best and there's an option to change but I got used to it. Recommend http://www.vimregex.com/ http://www.vimregex.com/ gv is quite handy when you want to reselect last to rerun a command on it too

sublinear 3y ago

I don't have a problem using both in their more or less default configuration. I use vscode for editing code without any special keybinds and just a couple of plugins for syntax highlighting. I use vim for everything else in the terminal window (also without plugins). I don't experience any speed difference or difficulty switching between the two. Yeah I'm going to say something blasphemous... they're about the same. Vim is just slightly jankier, but more mature/capable.

taf2 3y ago

Moving text is great in vim but being embedded in the terminal means all the powers of the shell are one ! away as well that makes it faster to do things… need a quick syntax check !node -c % , or need to run a command !ruby % It’s just faster when you are connected shell… and unlike vscode - vim is pushing 30 and the shell environment 40, I see very little reason the shell and vim will substantially change in the next 40 years… but I guarantee vscode will look very different… so learn a tool for life that will be just as powerful tomorrow as it is today

AdieuToLogic 3y ago
> Moving text is great in vim but being embedded in the terminal means all the powers of the shell are one ! away as well that makes it faster to do things… Quite true. Also, partial buffer manipulation can be done with external programs via range constraints. For example, to reverse sort only the first 5 lines of in buffer, one can execute this ex[0] command: :1,5 !sort -r 0 - https://man.freebsd.org/cgi/man.cgi?query=ex&apropos=0&sektion=0&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=ex&apropos=0&sekti...
- schoen 3y ago
  I like to use vi as a kind of IDE for shell commands, because you can, for example, !}somecommand to pipe a paragraph through that command, or 1G!Gsomecommand to pipe the whole editing buffer through that command, which is also equivalent to :1,$!somecommand which I find less obvious as a way to do that, even though it makes sense historically in terms of ed and ex. You can also, in vim, use u and ^R to undo your pipe transformation and redo it, so you're basically then doing a series of shell pipe transformations with interactive history. If you need to generate text with a shell command instead of pipe existing text through it, you can use :r!somecommand Commands that I like to use in this context include tac, rev, tr, cut, grep, and sed (although using sed this way is a little silly since the substitutions I'm doing are normally also available natively inside of vi itself). A simple example that I like a lot is 1G!Ggrep . which removes all empty lines from the current file. ("Line 1 go to line, pipe from here to result of movement go to end of file, command 'grep .' [print lines that match 'any character']") The classic ed/ex way to do this is :1,$g/^$/d which is just as many characters, but which requires lots of explicit thought for me, while the "1G!G grep ." version seems to no longer require explicit thought at all. ("For lines 1 to last line, repeatedly match ^$ [line beginning immediately followed by line end], delete matching lines.")

q7xvh97o2pDhNrh 3y ago

Wow, this is fascinating to hear. Other than the standard baseline of not touching the arrow keys, I use vim pretty differently: - 'j' and 'k' to move up and down, with '{' or '}' or even something like '20j' to move quickly - 'w' and '$' and '0' to move horizontally, with things like '5w' to move quickly I also rely heavily on 'v' and ctrl+'v' to select arbitrary shapes of text for yanking/deleting. I'm not sure what the exact takeaway is from comparing our styles, but it's interesting to realize about how much of coding comes down to just navigating up/down/left/right. I agree with your last couple paragraphs almost verbatim though! That StackOverflow answer is exactly the reason I decided to try vim and stuck with it. The verb/noun nature of vim makes it so easy to enter a flow state. The text editor fades into muscle memory, and you can surf waves of code with no bottleneck between mind and machine. (To write this comment, I actually had to open a random file and navigate around it while watching my hands — it's been years since I've thought about it!)

jrumbut 3y ago
I might be a perfect complement to the grandparent. I use w b $ and ^ to move horizontally. I like using w and b because then I can hit cw to make a small change. For vertical (I don't really think in terms of horizontal and vertical, I think about it as a streams of "words" and "spaces") I usually do a search (/ or ? to go up or down) or for some files I do 20j like you. Shamefully, I do sometimes use the mouse out of habit from other programs. I can't remember the last time I used f.
- dfinninger 3y ago
  I usually go for “ciw“ to make changes from wherever I am in the word. It lets me use w or e because I’m not usually paying attention to which one I’m smashing. :)
- bottlero_cket 3y ago
  f I use second most. It has so many uses all of which could be done with / command, but definitely you come to prefer f. I use f( to scan forward to the next open paren. Then I use di( to delete in parens for example to remove the arguments. Uppercase F does the same but backward up the text. Often I use f, to go to a comma. df, to delete up to the next comma as in removing just 1 argument. The only draw back is that f does not have any repeat shortcut like n for next or . for reapply, those do nothing for f. I should mention also that f works on a single line at a time unlike /

galkk 3y ago

I kind of settled on vim as console editor in Linux but it will never replace good ide for me, and modern ides are getting/having vim mode for navigation, making then even more compelling. * Do you want autodetect indent and tab rule in file? Install plugin. * Do you want to automatically insert matching closing parenthesis - rebind keys (half baked solution) or plugin. * Vertical scrollbar? Plugin * Autocomplete code using lsp? Dance with plugins or copy paste literal screens of configs for nvim * Want nice looking theme? Plugin! (Gruvbox in my case) * Install and manage plugins? 3rd party Plugin for that too, with init code that will clone it itself from GitHub * Wrap long lines by whole words if possible? No default setting, I guess I need to search for plugin for that too. List goes on and on, and it is just I’m looking at my vimrc and recalling why I added or another thing. And there are many things which I decided to just to not care about, because it requires too much time to get it work Parent mentioned refactorings, but trust me, no matter what typing/navigating speed is, the standard refactorings in modern ides (that I bet cover most of typical refactoring work) will work faster and more correctly than manually doing the same. Even basic things like projectwise method rename or extracting something to parameter. Almost every quality of life improvement that is standard in modern ides require tinkering with vim.

wruza 3y ago
That’s mostly true, but then one day you want to use an external filter, or a custom set of snippets that doesn’t suck at editing them, or make the next line align correctly after “(“ and there’s no plugin for that in your ide. And, more importantly, it’s a pita to create and publish one. It’s not better or worse, some people like off the shelf availability, some like local fine tuning. Would be nice to have a full union, but ides suck at local customization that wasn’t trivial or planned in advance. Added: I hate both worlds now. Where’s an editor that is full of modern features and at the same time easily programmable?
- pcblues 3y ago
  The last great effort with resources, experts, etc. was VSCode. If they can't nail it, can it be done?

eviks 3y ago

The greatest SO answer ignores the core issue "But you never know exactly if you've selected what you wanted." The solution to this is switching verb-object to object-verb like kakoune/helix do, but I guess that goes too much against the "zen of vim"

nsvd 3y ago
Why not just use visual mode to see what you're selecting?
- eviks 3y ago
  VISUAL always extends and clears selection on mode switching, so it doesn't fit. It's a bit challenging to explain in a brief comment, so maybe check "Improving on the editing model" section https://kakoune.org/why-kakoune/why-kakoune.html#_why_kakoune https://kakoune.org/why-kakoune/why-kakoune.html#_why_kakoun...
xigoi 3y ago
My problem with object-verb is that it requires much more keymaps for motions (you need to distinguish between “move selection” and “extend selection”).
- eviks 3y ago
  Extend selection is via the same select mode that vim already has, so that's 1 extra key prefix, and move selection is enabled by default, so regular move commands pre-select what they move over, so in some cases that's even saving you a keypress :) Though it's not that it should be the only way to go (plenty of vim pros have adjusted), it's just visual feedback is very powerful, and lack thereof is a legitimate big challenge you shouldn't ignore in the "greatest" answer
  - drbaba 3y ago
    I wonder how it would be if one attempted to make Vim’s verb-object system more visual instead? Imagine if say “dwww” would highlight the next three words in red to mark them for deletion - but until you press enter to execute the deletion, you remain in a visual-like mode where you can adjust the region you want to delete by pressing more motion keys. Similarly, pressing “yip}” could highlight two paragraph (in paragraph + next paragraph) in yellow and then yank them when you press enter. This would kinda be the opposite of the idea in Helix/Kakoune: one automatically enters a visual-mode-like state after typing a verb that expects an object.

gigatexal 3y ago

Kids these days and their addiction to electron smh ;) I think I’m only scratching the service with my neovim setup. But besides the plugins that make it a bit more like a full IDE I’m using some set of core commands, heavy use of visual selection and s/foo/bar etc. I learned a lot from this guide. I didn’t know about the f and t commands. Very cool.

hashar 3y ago

> Also, any chance I get to plug the greatest StackExchange answer ever, I will: https://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118 https://stackoverflow.com/questions/1218390/what-is-your-mos... You might consider posting that link a standalone entry on hacker news. That was a very great read well worth additional exposure. > "cdd" "@c" is effectively a finger macro for me That is pretty much how I use vi: muscle memory :]