Week 1: SmartMotion Vision & Road Ahead

[FluxxField]

Hey everyone — it’s been 1 week since launching SmartMotion.nvim, and I just wanted to take a moment to share the long-term vision and open up discussion.

Thanks to everyone who upvoted, starred, commented, or reported bugs — the feedback has been incredibly helpful.

---

What is SmartMotion really trying to solve?

There are already some great motion plugins out there: flash.nvim, leap.nvim, hop.nvim — they all bring something useful. But one thing they all share is that they’re opinionated and tightly coupled. You get their motions, their way. Want to modify it? You’re out of luck.

SmartMotion is not a motion plugin. It’s a motion framework.

The goal isn’t to compete feature-for-feature with flash or hop — the goal is to let you build your own motion systems from reusable parts.

---

What is a composable motion?

A composable motion is one that’s built from simple, interchangeable pieces:

• Collector – decides what raw content to look through (lines, buffers, Telescope results, etc)
• Extractor – breaks that content into targets (words, text ranges, nodes, etc)
• Filter – filters targets down to the subset you care about (after cursor, visible only, etc)
• Selector – allows you to optionally pick the first, nearest, nth, etc
• Modifier – post-processes the target or assigns metadata like weight (e.g., Manhattan distance), used to sort or influence label assignment
• Visualizer – shows the targets visually (hints, floating picker, Telescope, etc)
• Action – what happens when a target is selected (jump, yank, delete, surround, open file)

Each module is pluggable. You can mix and match to build any motion behavior you want.

There’s also a merging utility that lets you combine multiple filters, actions, or modifiers into one. Want to filter for visible words AND after the cursor? Merge both filters. Want to jump and yank? Merge both actions.

---

Why is this powerful?

Because you can:

• Build your own motions without writing new plugins
• Reuse core parts (e.g. "filter words after cursor") across different behaviors
• Create motions that match your personal workflow
• Extend existing motions with new ideas or plugin integrations

It turns motions into recipes.

For example:

A motion like s that jumps to a word after the cursor using labels:

register_motion("s", {
  collector = "lines",
  extractor = "text_search",
  filter = "filter_words_after_cursor",
  selector = "wait_for_hint",
  visualizer = "hint_start",
  action = "jump",
})

A motion like dt that deletes until a character (but shows labels):

register_motion("dt", {
  collector = "lines",
  extractor = "text_search",
  filter = "filter_words_after_cursor",
  visualizer = "hint_start",
  action = merge({ "until", "delete" }),
})

A motion that surrounds the selected target:

register_motion("gs", {
  collector = "lines",
  extractor = "text_search",
  filter = "visible_words",
  visualizer = "hint_start",
  action = merge({ "jump", "surround" }),
})

These are built entirely from modular parts. No custom code needed.

You can also create hot shot motions by skipping the visualizer entirely — these will automatically apply the action to the first matching target. This is perfect for cases where you don’t need to choose and just want speed.

---

Cutting down on mappings with inference

Right now, most motion plugins require you to map every behavior to a separate key: dw, yw, cw, etc. But with SmartMotion, the goal is to map fewer keys and let the framework infer the rest.

For example:

• You map just the key d to SmartMotion
• SmartMotion sees that d is mapped to the delete action
• It then waits for the next key(s) within a configurable timeout (e.g. w)
• w maps to the words extractor

So, hitting dw gives SmartMotion all it needs:

• delete action from d
• words extractor from w

It then composes the rest from configured defaults (like filters, visualizers, etc) to execute a composable motion.

This will allow you to:

• Use just d, y, c, etc. as entrypoints
• Cut down drastically on mappings
• Let SmartMotion infer motions intelligently based on input context

---

Flow State & Target History

SmartMotion also introduces the concept of Flow State:

• You can chain multiple motions together in one seamless editing flow
• Labels intelligently update as you go
• Holding down motions (like j) disables labels and falls back to native movement — best of both worlds

There’s also a planned Target History system, which allows for two types of repeating motions:

1. Repeat the same motion — e.g. keep jumping to next word with the same config
2. Repeat the same target type — e.g. repeat "next import line" motion with the same filter/extractor combo

This opens the door to complex workflows like smart repeat, repeat-last-target, or even undoing and reapplying targets with different actions.

---

Integrating with other plugins

The biggest opportunity is for other plugins to build their motions using SmartMotion instead of reimplementing everything.

Imagine:

• Telescope registering a collector and visualizer to turn SmartMotion into a motion-over-Telescope picker
• Harpoon using SmartMotion’s visualizers and filters to jump to recent files or marks
• Treesitter plugins using extractors to hint at nodes or functions

If your plugin exposes a list of targets, you can register:

• a collector (where to look)
• a visualizer (how to show it)
• an action (what to do after selecting it)

And gain full access to:

• Flow State chaining
• Motion history
• Selection + modifier logic
• Future visualizer upgrades

All without rewriting a motion system from scratch.

---

I want your feedback

I’d love to hear:

• What use cases would you want to build?
• What other types of modules would be useful?
• What’s missing in other motion plugins you’ve tried?
• What plugins would be exciting to integrate with?

Thanks again to everyone who’s tried SmartMotion so far — this is just the beginning, and I’m excited to see where it goes next.

Let’s build something powerful together.

— Keenan (FluxxField)

Note: Many of the ideas above — such as inference, target history, hot shot motions, dynamic merging, and plugin integrations — are still in development or experimental. The vision is long-term, and this framework is still evolving rapidly. Expect breaking changes and lots of iteration!