HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
easymotion
vim-easymotion
Vim Script2011–2025
easymotion / vim-easymotion

vim-easymotion

Vim motions on speed!

35Distinct people
38Mentions
2Explicit recommenders
7.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Vim motions on speed!

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Truly - moving off my triple headed desktop to my X1 carbon is always jarring, especially with merging. A few things that have helped me working with constrained real estate:…

RobSpectre used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year38 dated mentions

Observed mentions: 2011-10-17 18:37:10 UTC to 2025-03-18 04:49:57 UTC.

02462011-01-01 00:00:00 UTC to 2012-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20112012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20112011-01-01 00:00:00 UTC2012-01-01 00:00:00 UTC101
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC404
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC615
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC606
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC505
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC303
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC303
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Vim motion on speed! About the authors Authors Kim Silkebækken https://github.com/Lokaltog haya14busa https://github.com/haya14busa The EasyMotion project, revived! Starting from version 2.0 haya14busa will be taking over the project from Lokaltog. He's improved the default motions, implemented many useful new features, and fixed some bugs. EasyMotion is now completely: Well-behaved: It's consistent with the default motions of Vim and works well in all modes. And it now supports repeating with the dot operator. Configurable: You can easily configure its behavior and map it to any key Sophisticated: Provide flawless, smooth and fast motions with minimal keystrokes Even though some default behaviors were modified and many new features were added, I carefully considered backward compatibility. So those of you updating from older versions can do so without worry and start benefiting immediately from all the new features! Introduction EasyMotion provides a much simpler way to use some motions in vim. It takes the <number> out of <number>w or <number>f{char} by highlighting all possible choices and allowing you to press one key to jump directly to the target. When one of the available motions is triggered, all visible text preceding or following the cursor is faded, and motion targets are highlighted. EasyMotion is triggered by the provided mappings. This readme only covers the basics; please refer to :help easymotion.txt to see all the available mappings. Important notes Default bindings The default leader has been changed to <Leader><Leader> to avoid conflicts with other plugins you may have installed. This can easily be changed back to pre-1.3 behavior by rebinding the leader in your vimrc: map <Leader> <Plug>(easymotion-prefix) All motions will then be triggered with <Leader> by default, e.g. <Leader>s, <Leader>gE. For users of the forked version SelectLines and SelectPhrase are not actually motions, so I've moved them into separate plugins. https://github.com/haya14busa/vim-easyoperator-line https://github.com/haya14busa/vim-easyoperator-phrase Usage example for the base features <cursor>Lorem ipsum dolor sit amet. Type <Leader><Leader>w(<Plug>(easymotion-w)) to trigger the word motion w. When the motion is triggered, the text is updated (no braces are actually added, the text is highlighted in red by default): <cursor>Lorem {a}psum {b}olor {c}it {d}met. Press c to jump to the beginning of the word "sit": Lorem ipsum dolor <cursor>sit amet. Similarly, if you're looking for an "o", you can use the f motion. Type <Leader><Leader>fo, and all "o" characters are highlighted: <cursor>L{a}rem ipsum d{b}l{c}r sit amet. Press b to jump to the second "o": Lorem ipsum d<cursor>olor sit amet. Jeffrey Way of Nettuts+ has also written a tutorial about EasyMotion. New features in version 3.0 Overwin motions EasyMotion now supports moving cursor across/over window. Since it doesn't make sense that moving cursor to other window while Visual or Operator-pending mode, overwin motions only provides mappings for Normal mode. Please use nmap to use overwin motions. Overwin motions only supports bi-directional motions. Example configuration " <Leader>f{char} to move to {char} map <Leader>f <Plug>(easymotion-bd-f) nmap <Leader>f <Plug>(easymotion-overwin-f) " s{char}{char} to move to {char}{char} nmap s <Plug>(easymotion-overwin-f2) " Move to line map <Leader>L <Plug>(easymotion-bd-jk) nmap <Leader>L <Plug>(easymotion-overwin-line) " Move to word map <Leader>w <Plug>(easymotion-bd-w) nmap <Leader>w <Plug>(easymotion-overwin-w) Integration with incsearch.vim haya14busa/incsearch.vim haya14busa/incsearch-easymotion.vim " You can use other keymappings like <C-l> instead of <CR> if you want to " use these mappings as default search and sometimes want to move cursor with " EasyMotion. function! s:incsearch_config(...) abort return incsearch#util#deepextend(deepcopy({ \ 'modules': [incsearch#config#easymotion#module({'overwin': 1})], \ 'keymap': { \ "\<CR>": '<Over>(easymotion)' \ }, \ 'is_expr': 0 \ }), get(a:, 1, {})) endfunction noremap <silent><expr> / incsearch#go(<SID>incsearch_config()) noremap <silent><expr> ? incsearch#go(<SID>incsearch_config({'command': '?'})) noremap <silent><expr> g/ incsearch#go(<SID>incsearch_config({'is_stay': 1})) Bonus fuzzy-search with EasyMotion haya14busa/incsearch.vim haya14busa/incsearch-fuzzy.vim haya14busa/incsearch-easymotion.vim function! s:config_easyfuzzymotion(...) abort return extend(copy({ \ 'converters': [incsearch#config#fuzzyword#converter()], \ 'modules': [incsearch#config#easymotion#module({'overwin': 1})], \ 'keymap': {"\<CR>": '<Over>(easymotion)'}, \ 'is_expr': 0, \ 'is_stay': 1 \ }), get(a:, 1, {})) endfunction noremap <silent><expr> <Space>/ incsearch#go(<SID>config_easyfuzzymotion()) New features in version 2.0 Two key highlighting When EasyMotion runs out of single characters to highlight movement targets, it immediately shows you the keys you have to press. In previous versions you could not see the next character you would need to press until you entered the first one. This made movement over long distances less fluid. Now you can see at a glance exactly which characters to select to get to your destination. Bidirectional motions All motions now come in bidirectional variants (e.g. <Plug>(easymotion-s), <Plug>(easymotion-bd-w) and so forth). By default, you can already jump forward or backward with <Leader>s. A useful trick is to map nmap s <Plug>(easymotion-s) to use s instead and save one keystroke! 2-character search motion You can now also perform a 2-character search, similar to vim-seek/vim-sneak with <Plug>(easymotion-s2). For example, you can highlight all words that start with fu. " Gif config nmap s <Plug>(easymotion-s2) nmap t <Plug>(easymotion-t2) n-character search motion You can also search for n characters, which can be used to replace the default sea
Read the full README on GitHub

What Hacker News says

38 sources
So many ways! fa; (f)find (a) (;)repeat That would be the generic vim way. I could mash on semicolon to get to each instance of "a" in the line. Here's another. 2fa 2 (2nd instance) f (find) (a) Most people use a plugin called easy motion instead. You type some two character key command to start it. For me it's "ff". After ff, i type any two characters. It will then highlight each place in the document that start with those two characters (think an inline table of contents) that I can then select. https://github.com/easymotion/vim-easymotion I write all this knowing it looks and sounds like madness, so again, don't take this as anything other than someone explaining their madness, but once you learn all this stuff (it takes about a month) you realize your mouse is actually the slowest way to do it.
In Past and Present Futures of User Interface Design
Hm - I can't see how this is functionally significantly different than EasyMotion[1] or Sneak[2]. Not a knock on it - just curious if I'm missing something. My problem with these types of plugins is that, although it's a bit more annoying to type out a few more characters, with my vanilla Vim workflow I can pre-compute the motions in my head - I can figure out I need to type d7l or whatever way before I get to the point in my editing where I need to, and as I'm typing it out I'm already thinking about what I want to do next. With sneak, easymotion, or leap, it looks like I can't actually figure out what keys I need to press to get to where I want until I've already started the motion. That means I need to take some time to read the label, etc. So maybe I've saved a few milliseconds of not having to type one or two more keys, but I lose th
Read the rest
at and more by having to parse what to do. Curious about other experiences and if I'm off base though. [1]: https://github.com/easymotion/vim-easymotion [2]: https://github.com/justinmk/vim-sneak
In Leap: Neovim’s Answer to the Mouse
> I’m not really sure what you’re getting at. I'm disagreeing with your assertion that "it's logically almost certain that a good trackpad is more efficient than any combination of keyboard shortcuts". I thought you were talking about moving the cursor to a general area of the screen, not within the context of a text buffer, but there I still think using the keyboard for motion is more efficient once you build up the muscle memory for it. There are plugins like vim-easymotion[1] that make this faster, but I've found plain motion bindings to be efficient enough for me. In any case, my intention wasn't to dismiss your personal preference, so apologies if it came out like that. At the end of the day we all have a specific workflow we prefer for whatever reason, and that's fine. I just objected to the general statement that a trackpad is more
Read the rest
In Helix: a post-modern modal text editor
Let me sketch you something of a theoretical proof here, then. 1) Any command you can issue by clicking or scrolling on something, can also - in principle - be issued by pressing a key on a keyboard. Therefore, any automation you hide under a mouse-activated command doesn't matter, as it can be invoked by keyboard too, and faster. 2) The absolute upper bound on the simplest possible way of aiming at a single pixel of 4K UHD screen with just two keys is 23 key presses. 14 key presses if you're aiming at 16x16 squares (mouse rarely needs to aim better). 12 keypresses for arbitrary pixels with four keys (home row). 8 for 16x16 square with four keys. 5 presses with full set of English letters, for arbitrary pixels. That's an upper limit. It's slower than a mouse, but only by a little bit (within the same order of magnitude). 3) Generalizing t
Read the rest
his, the upper bound of keypresses you need to touch arbitrary element on the screen is given by log_n(number of elements), where n=how many keys you want to use. +1, if you need some sort of activation key before (to switch between typing and selecting). This quickly drops to 1-3 keys, and you can get even better if there's some structure to the expected workflow (see e.g. tab stops in any sane form in any UI that isn't suffering from acute JavaScriptitis yet). 4) 1-3 random keys are faster to press than clicking a random object on a screen. That you can time for yourself trivially. Basically, unless you're dragging arbitrary pixels around, for almost[0] any task one could easily design a keyboard-driven UI that's faster. Those kinds of UIs are not omnipresent (with the exception of Windows-style "accelerators" and tab stops, which the web is doing its best to get rid of), but they show up. In fact, properly configured Vim and Emacs are full of these kinds of UIs for programming tasks (see e.g. [1]). Which is exactly why you keep seeing people telling you Vim/Emacs are more efficient to work in. -- [0] - I'll make concession to visual arts here, but take a good look at Blender to see how far you can go with keyboard-driven efficiency improvements for 3D modeling. [1] - https://github.com/easymotion/vim-easymotion; Emacs has stuff like this too, but this repo has better screenshots.
In How I'm still not using GUIs in 2019: A guide to the terminal
OP here. Thanks for the tips. I've used vim-sneak for quite a while (it's even built into Visual Studio Code's Vim plugin), but it just didn't work with me. I'm more of an easymotion (https://github.com/easymotion/vim-easymotion) type of guy. But even easymotion vanished from my workflow, because `/` works almost equally well for me and easymotion is not available on every system I use. I guess what I'm trying to say is that I became more and more conservative about what external dependencies to rely on, because as soon as they become part of my workflow, I can't easily go back because they become part of muscle memory. For vim-move I use `V` + `j,k` for the selection followed by `d` to delete and `p` for paste. Works quite well for me. The problem that I have with visual selections is, that I often want to "grow" a selection from inside
Read the rest
of my current position. Say my cursor is inside parentheses, I'd like to hit a key repeatedly to select an ever growing region of text: first the entire content inside the parentheses, then including the parenthesis, then the entire line, then the entire function and so on. Is there a plugin for that? Thanks for your article on buffers. Looks like a great workflow. What I'd like to have on top of that is a way to open a buffer based on the contents of a file. Say I have a file somewhere that contains a specific function, `myFunction()`. I'd love to just start typing `myFu` and vim would suggest the correct file to open. Bonus points for handling typos, e.g. `ymFu` should also work.
In Ten Years of Vim
For vim there are plugins like EasyMotion[1], and for emacs there's Ace Jump Mode[2], which let you precisely get to any character on the screen with a couple of keystrokes. These plugins really revolutionized my vim and emacs usage. Then there's also the ability of vim and emacs to quickly and precisely select text objects like words, paragraphs, functions, etc (even when they may span more than one screen). There's just no way a mouse can be anywhere near as fast as doing that for larger objects, and using the mouse is much more error-prone. [1] - https://github.com/easymotion/vim-easymotion [2] - https://github.com/winterTTr/ace-jump-mode
In Is the keyboard faster than the mouse?

Showing the 15 most recent of 38 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.