Trying to move away from arrow keys in normal/insert/visual mode, but small text inserts are killing me!

Question

I've disabled my arrow keys, and am finally getting used to hjkl (for the longest time I'd always hit j and k the wrong way around - just seemed more natural for some reason).

In normal mode I'm fine with it, but not being able to move the cursor in insert mode is killing me.

Frequently I want to make lots of short changes to a few lines near each other. Previously this was a doddle with a couple of taps of arrow keys, but having to leave insert mode, move then re-enter insert mode is incredibly tedious - it means I end up reaching for the mouse instead, which isn't what we're aiming for with vim!

What's your solution?

Answer 1

I believe that the art of Vim has nothing to do with disallowing any tools available for you, but rather finding the best (i.e., most efficient) path to altering text. The truth is that sometimes the arrow keys really are the most efficient. This is particularly true in cases where several small insert-mode changes need to be made that are interspersed with several small navigations.

Here is a small test to illustrate this:

Fast: Using Arrow Keys (Insert Mode)

Slow: Using HJKL Navigation (Normal Mode)

Using arrow keys here is clearly faster. Not only does exiting and re-entering insert mode cost extra keystrokes, but it also requires the user to reset their left hand position. A different set of characters to add (maybe more right-hand focused) could change the results, but I believe the effect would be similar.

Here is a similar example where HJKL navigation will typically prove better:

Slow: Using Arrow Keys (Insert Mode)

Fast: Using HJKL Navigation (Normal Mode)

When it comes down to it, all we can do is to approximate the fastest path. Oftentimes this is best without arrow keys, and this is where Vim shines -- we could all share countless tricks and tools for normal mode manipulation. But, sometimes, there's just nothing better than arrow keys.

Answer 2

My solution is to use everything vim offers me: HJKL, /, FftT, {n}w/b/e, ^, $, %, [], ][, [{, and also arrow keys, control arrow keys, home, end, Pg Up and Down, the mouse...

Arrow keys and hjkl are both as inefficient when moving around. If the need is only to move of a couples of characters or lines, they are perfect. For more, Vim has better solutions. They come with time.

Try to think about what you want to do: move to the next Word, the beginning of the current function... instead of moving to the position you see with your eyes.

Answer 3

In general I try to stay out of insert mode as much as is humanly possible. (A fact I alluded to in the comments.) Most of the time, for lots of small edits I make to nearby lines, I will endeavour to enter insert mode only once.

For your given example of changing getVal to get_val on two consecutive lines with the cursor starting far from the first edit point, what I'd most likely do in practice is:

1. /getVal<CR> Jump to first location.
2. ciwget_val Make the edit. fVsv_ is fewer keystrokes, but wouldn't, for me, actually be any quicker to type, and also it would prevent me from performing the edit on the next line simply with...
3. n. Jump to the second location and make the change again.

If the cursor starts after the edit points, instead of before, I'd substitute ? for / in step 1.

If the cursor starts near to the edit points, I'd instead use whatever other motions are quickest (which hopefully doesn't include hjkl) to get there, and then press * to set up my search register (without moving the cursor, because I have * mapped to *<C-O>), and then continue with steps 2 and 3.

Answer 4

This answer might not be able to cover all cases where you see yourself doing many small edits on different locations of the same line, but I find that a good approach here is to try and turn them from many separate small insertions into a Normal mode action.

That often means adopting plug-ins implementing more complex actions, or also advanced text objects that can help select the right bits of text to act upon.

In the comments, you mentioned refactoring to replace getVal with get_val. Plug-in vim-abolish has a "coerce" operation under cr to do case coercion, using crs will perform case coercion to snake case on the current word, which is the transformation you're after. (cr_ also works.)

Another type of refactoring that typically involves small edits interspersed with movements is adding braces or parentheses around text. Plug-in vim-surround can help with that. You can surround text with ys, for example ys"iw to put double quotes around the current word. Or replace types of braces, cs]) to replace square brackets with parentheses. You can also use visual mode to select which text to surround.

For advanced text objects, I recommend targets.vim, which introduces some useful text objects for arguments of functions that can also be very helpful when refactoring code. It also introduces modifiers for the "next" (n) and "last" (l, more like "previous") text object, so you can act further away on the line you're in. For example, you can use dana to delete the "next" argument if you're on top of a function call or an argument of a function call. Plug-in targets.vim includes many other helpful text objects and it also extends some built-in text objects in Vim to make them smarter.

Make sure you also have vim-repeat, which will allow you to use . to repeat actions from plug-ins such as vim-abolish and vim-surround (among many others), which is important if you're using these actions repeatedly on many separate lines or matches.

In short: Try to reframe your small edits into an "action", which you'd execute in Normal mode, and consider embracing plug-ins which implement such actions for you.

Answer 5

People always think the advice for disabling the arrow keys is so you will use hjkl instead, but it's really so you will get used to using normal mode in general. Normal mode is where you get all your efficiency gains.

As others have pointed out, yes, there are situations where an arrow key is faster than using normal mode to move one square, but most of the time, you aren't moving just one square. Forcing you into normal mode hopefully encourages you to learn and use those shortcuts that work by lines and words and marks and patterns.

At a certain point, you don't even think about switching back into normal mode. You just always seem to be in it, and occasionally you realize after the fact that just hitting an arrow key would have been faster. That's when I recommend re-enabling your arrow keys.

That being said, ultimately the way you learn and use the tool is up to you. Just be aware that the fastest vimmers are normally in normal mode.

Answer 6

having to leave insert mode, move then re-enter insert mode is incredibly tedious

I imagine most of the tedious part is leaving insert mode, which implies reaching for the Esc key. Personally, I have my CapsLock mapped to Esc (with setxkbmap -option caps:escape), but there are multiple alternatives, like mapping jj to leaving insert mode, etc.

I actually switch more than necessary, and don't see it as a hassle. It's because I'm thinking of a series of actions and my fingers just translate. Let me give you an example. Let's say that I want to

1. call foo
2. pass it an object
3. make it a multiline object
4. pass it field bar with value "baz"

I don't foo({EnterTabbar: "baz"EnterBackspace}).

Instead I do:

1. foo()Caps (call foo)
2. i{}Caps (pass it an object)
3. iEnterCaps (make it a multiline object *)
4. koTabbar: ""Caps (add field bar) **
5. ibazCaps (with value "baz")

I think I don't see it as a hassle because:

1. I've made it easier to exit insert mode, by using Caps
2. Typing like that allows me to take advantage that opening and closing braces of all types are right next to each other on a QWERTY keyboard. This also allows me to hit " twice in succession when typing strings. It limits how many times I need to move from typing words to "weird" keys.
3. This is the big one for me: It better maps editing actions I have in mind to key sequences I need to type. It's like it makes typing more composable. I think this allows me to use muscle memory better when editing text.

_{* When I know from the get-go that I want a multiline object, I'll just {Enter} directly. Since it's just a common thing to do and the keys are so close to one another, it's already in my muscle memory. I would do it like I listed above if I wasn't sure at first, though, or if the keys were different.}

_{** I use ko because O immediately after Esc corresponds to some terminal escape sequence, so weird stuff happens.}

Answer 7

I have a non standard solution for the need to press esc too often: Map ` to be insert mode enter & leave. If I need to insert `, I mapped ctrl-] for that (rare). For ` in normal mode, I mapped ! (not needed that often so shift-1 is ok) And ctrl-` for ctrl-o for fasted movement .

I have another solution of leaving insert mode on timeout but found it not useful.

Answer 8

I use the arrow keys a lot, but rebound them to automatically exit insert mode, as shown below. In my experience, it quickly becomes second nature to navigate with hjkl when you know what mode you're in and with the arrow keys when you're in insert mode or aren't sure.

inoremap <left>  <esc>
inoremap <up>    <esc><up>
inoremap <down>  <esc><down>
inoremap <right> <esc>l

Overall, it is very convenient and works well with one's intuition. It does make using visual block mode more annoying though, since your navigation options when creating a small bit of text to Insert or Append are more limited.

You might also consider just rebinding the up and down keys.

inoremap <up>    <esc><up>
inoremap <down>  <esc><down>

That way, moving around within a line doesn't change the mode you're in, but leaving the line does.