This is something that has bugged me for a long time, but I've never gotten around to asking about. Say the text in your buffer looks like this:


If I put my cursor somewhere in line 2, and do yk, my cursor will end on line 1. This seems to imply an operator plus a motion also moves the cursor. However, if I start on line 1 and do yj, my cursor remains in the same spot. The same inconsistency happens with a lot of keys.

Moves   Doesn't move
gg      G
h       l
{       }
(       )
T       t
F       f
?       /

So what's with this behavior? Is this expected and well documented? Is there a name for this? Can it be overridden?

In general, it seems like "Backwards moves, forwards does not", but is there a way I can definitively tell whether or not an operator+motion will move the cursor or not?

  • 2
    y is an operator, not a command.
    – romainl
    Jun 2, 2016 at 6:10

2 Answers 2


From :h operator

After applying the operator the cursor is mostly left at the start of the text that was operated upon. For example, "yfe" doesn't move the cursor, but "yFe" moves the cursor leftwards to the "e" where the yank started.

What's happening is that the cursor is being moved to the beginning (where beginning means: first character for characterwise text objects and first line for linewise text objects) of the text object. Enabling visual mode will make it more apparent. You can think of it as the text is being selected before it is operated on. Use vby to see what I mean.


For yanking, a workaround (inspired by 1) is to add the following mapping: nnoremap y m`y. Now every yank will create a mark that you can later return to with ``. Maybe even create nnoremap <BS> `` to make it easier.

EDIT: It's actually a bad idea. This prevents from selecting desired register with " before yanking.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.