New motion command proposal

70 views
Skip to first unread message

Iago Jacob

unread,
Jun 11, 2025, 2:39:59 AM6/11/25
to vim...@vim.org
[Proposal] New motion command: `binsearch` for binary-search-style line
navigation

Hi fellow Vim enthusiasts,

I'd like to propose a new motion command for Vim: `binsearch`, which
facilitates precise cursor movement in **normal** and **visual** modes
using a binary search approach.

---

###  Problem

Currently, if a user wants to jump to a specific line **visibly** on
screen, they must resort to one of the following:

1. Use `H`, `M`, `L`, and then mash `j`/`k`.
2. Use `<n>G`, which requires knowing the exact line number (often a
large number).
3. Use `/pattern`, which may jump thousands of lines off-target.

All of these are either cumbersome, error-prone, or break concentration.

---

###  Proposal: `binsearch` Motion

* **Trigger keys**:

  * `Ctrl-Q`: Begin or reset binary search session.
  * `Ctrl-J`: Move downward (toward lower bound).
  * `Ctrl-K`: Move upward (toward upper bound).

* **How it works**:

  * Pressing `Ctrl-Q` starts a binary search session. It sets the upper
and lower bounds to the **top-most** and **bottom-most** visible lines.
  * Pressing `Ctrl-K` or `Ctrl-J` then performs binary search: the
cursor jumps to the midpoint between the current position and the
respective bound.
  * Each jump updates the appropriate bound.
  * Pressing `Ctrl-Q` again resets the session.

* **Example use case**:

```
line 1 aaa...
line 10 bbb... <-- Ctrl-J
line 20 bbb... <-- Ctrl-K
line 30 ccc... <-- <cursor>
line 40 ddd...
line 41 ...
```

To reach line 30 directly, only **4 keypresses** may be needed — a big
win in both speed and ergonomics. Because of binary search's logarithmic
efficiency, it converges in a small number of steps (e.g., \~5 steps for
52 lines of height).

---

###  Implementation Notes

* Patch introduces `nv_binsearch()` in `src/normal.c`, and the command
is registered in `src/nv_cmds.h`.
* Documentation is added to `/runtime/doc/index.txt` and
`/runtime/doc/motion.txt`.
* This implementation is **functional** and works in **normal** and
**visual** modes. Cursor updates are immediate so visual selections
respond naturally.
* Patch file is attached to this email

---

###  Alternatives Considered

* **Operator-pending mode** is not currently supported, though this can
be added by delaying motion until the final step (similar to how `G`
behaves).
* A plugin was considered, but this functionality touches core motion
behavior and is best integrated natively. Also, plugins increase setup
complexity, especially for new users.

---

###  Tested

* Built and tested on Ubuntu — works as expected.

---

Any feedback on this command or implementation direction would be highly
appreciated. If there is interest from the community, I’d be happy to
adjust the patch to better integrate with Vim's existing motion semantics.

Thanks for your time and attention!

Best regards,
Iago Jacob
iagoj...@gmail.com
0001-patched-binsearch-normal-mode-command.patch

Christian Brabandt

unread,
Jun 11, 2025, 4:12:04 PM6/11/25
to vim...@googlegroups.com, vim...@vim.org
Thanks, this is an interesting feature. I seem to remember a previous
discussion about this, but couldn't find it.

Regarding the keys, we need to think about others however, CTRL-Q is
used on Windows to start a visual selection, Ctrl-J might be okay (not
sure, it may break Enter or Carriage Return key) and Ctrl-K seem unused.
Perhaps we can use CTRL-\ CTRL-R (to reset), CTRL-\ CTRL-H to move to
upper bound and CTRL-\ CTRL-L to lower bound (similar to H and L).
Although those are key combinations but users could easily map it if
they need an easier way for it.

Once we have this, people may also want to have this for horizontal
scrolling, so we may want to thing about keys for horizontal movements.

How does this work in operator pending mode (e.g. after a d command)? It
doesn't seem to be very useful in that mode, since one may not know
exactly where it jumps and you probably cannot chain those keys until
the final position. So not sure if this makes sense.

Does it support counts?

I haven't looked yet at the implementation, but I'd encourage you to
create a PR at the vim github repository so we can see the results of
the test suite directly and review it easier.

Also, please add tests to it, check e.g. testdir/test_normal.vim and
please also include tests for visual and operating pending mode.

What do other people think?

Thanks,
Christian
--
I was in Vegas last week. I was at the roulette table, having a lengthy
argument about what I considered an Odd number.
-- Steven Wright
Reply all
Reply to author
Forward
0 new messages