[HN Gopher] Moving fast with the core Vim motions
___________________________________________________________________
Moving fast with the core Vim motions
Author : mooreds
Score : 38 points
Date : 2023-06-13 15:49 UTC (1 days ago)
(HTM) web link (www.barbarianmeetscoding.com)
(TXT) w3m dump (www.barbarianmeetscoding.com)
| sva_ wrote:
| I think the article is missing ctrl-y move up 1
| line without moving cursor ctrl-e move down 1 line without
| moving cursor ctrl-b move up 1 page, placing cursor on last
| line ctrl-f move down 1 page, placing cursor on first line.
|
| These are really useful when looking around without wanting to
| edit.
| grelek wrote:
| Thanks, didn't know about these.
| sodapopcan wrote:
| I've always used ctrl-e and ctrl-y with `:set scrolloff=2` to
| make it a bit quicker. It was one of the first things I learned
| as I found ctrl-d and ctrl-u incredibly jarring and thought
| there must be another option.
| lkbm wrote:
| "Vim as a Language"[0] is a similar article I benefited greatly
| from back in the day.
|
| One additional tip once you start using things like d8k: Try "set
| relativenumber" in your vimrc. It makes all except the current
| line display offsets rather than absolute line numbers.
|
| Initially, this seems silly, but you quickly realize that if
| you're at line 1668 and need to delete up to line 1619, it's much
| more helpful to see line 1619 listed as "line 49" rather than
| "1619" and having to do the mental math to figure out that the
| command you're looking for is "d49k".
|
| [0] https://benmccormick.org/2014/07/02/062700.html
| lachlan_gray wrote:
| I wonder if eye tracking could be used as a vim motion if it
| becomes really good on new vr/ar headsets. Vim is already fast,
| but...
| stevebmark wrote:
| To move fast, use the mouse[1]. Trust me. I've played that game
| of always trying to find the most efficient way to target
| something on the screen in Vim. If you haven't already learned
| about EasyMotion, tried it, and gave it up, you probably haven't
| tried to perfectly optimize your movement in Vim. It's not a game
| worth playing. Figuring out how to navigate your screen with the
| keyboard is a Vim problem: editing text now is something you have
| to think about, _a lot._
|
| [1]There is no conclusive evidence that Vim's motions help you
| type nor navigate faster
| 2023throwawayy wrote:
| It is simply not possible for me to disagree harder with
| everything you said.
|
| I don't think at all about editing text. Using vim is so
| natural, and so, so much faster.
|
| I watch my mouse-bound colleagues when they screen share on an
| almost daily basis. It's painful to watch. I am far faster with
| vim.
| weitzj wrote:
| My sweet spot right now is Vim + i3 (or sway) + udxvtd and a
| fixed trackball on the desk
| mikemallon99 wrote:
| When you first starting Vim motions you'll be putting thought
| into it, because it takes time to develop your muscle memory
| and learning where the motions are useful. But once you get
| going, it feels so much faster than using a mouse.
|
| Just being able to use a keystroke to copy or replace text
| inside a set of parenthesis is so much faster than clicking and
| dragging your mouse cursor inside the set of parenthesis.
|
| Not sure who is collecting the data on Vim motions being faster
| than mouse, but just from experience it feels way faster and
| more satisfying than using a mouse.
| penjelly wrote:
| its not about perfect movement. Its about keeping your hands on
| the keyboard, fewer keystrokes (over using arrow keys), and
| being more precise. The idea also isnt to think super hard
| about what to press next, the movements become 2nd nature, so
| you're barely thinking about them. sorta like when you type a
| sentence you dont think consciously of each character, your
| brain mostly relies on muscle memory to reach the keys
| necessary.
|
| edit: before i get flamed, im NOT saying you NEED to use vim to
| be the most productive. The best devs on my team DO NOT use it.
| So its not necessary, but it is a lever some can pull and
| benefit from.
|
| also, your quote/citation doesnt provide any value. Just
| because there isnt a study on vim doesnt mean it doesnt
| increase productivity..
| tmtvl wrote:
| Using the mouse only really works in Acme, every other editor
| makes you switch between mouse and keyboard way too much. The
| mental and temporal overhead of switching makes it severely
| unoptimal. Maybe it would work better using (left|right)-handed
| Dvorak or a Mother-of-all-Demos-style chording keyboard.
| jrib wrote:
| Part of the appeal for me is not having to move my hand to the
| mouse and back.
| auto wrote:
| 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-mos...
| weaksauce wrote:
| vscode with the neovim extension is awesome... almost perfect.
| b33j0r wrote:
| 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.
| weaksauce wrote:
| 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.
| ziftface wrote:
| I've had great luck with nvim-dap and nvim-dap-ui.
| Foxboron wrote:
| vimspector is a cool DSP for vim.
|
| https://github.com/puremourning/vimspector/
| cassepipe wrote:
| 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/
|
| gv is quite handy when you want to reselect last to rerun a
| command on it too
| u801e wrote:
| It's also missing H, M, and L for moving the cursor to the top,
| middle, and bottom of the window respectively. You can also
| navigate using the % command. For example, you can use 50% to
| scroll to the middle of the file, 75% to go down 3/4ths of the
| way, etc.
| j2kun wrote:
| Not to mention using the % key for jumping to the matching
| bracket. Or tree-sitter for navigating scopes
| peoplearepeople wrote:
| That page is really hard to read on a desktop monitor, everything
| is huge and wide
| Gualdrapo wrote:
| Not everything - the code blocks take the full width of the
| page and break the reading flow so hard.
|
| Also the font title is just huge and so bold. Even on a narrow
| window.
___________________________________________________________________
(page generated 2023-06-14 23:00 UTC)