🚀 New Engine and Exit Event System in SmartMotion.nvim

[FluxxField]

Hey everyone! I’ve just pushed a major internal refactor to SmartMotion that lays the foundation for powerful new features going forward. This post is a deep dive into what’s changed, why it matters, and where we’re headed next.

---

🔧 Why Refactor the Old Dispatcher?

Previously, SmartMotion used a module called dispatcher.lua to run motions. But over time it became clear that:

• The name “dispatcher” didn’t reflect what it was really doing.
• We had two nearly identical functions (trigger_motion and trigger_action) doing very similar things.
• All logic (setup, execution, exits, inference) was tightly coupled and hard to extend.

To fix this, I completely overhauled the system and introduced a brand new engine architecture.

---

🧠 The New Engine Structure

The motion runner is now broken into clean, single-responsibility modules under lua/smart_motion/engine/:

• init.lua: Entry point for triggering motions
• setup.lua: Gathers and prepares all necessary data
• infer.lua: Handles module inference (e.g. choosing extractor based on input)
• loop.lua: Core execution loop that processes generators
• pipeline.lua: Runs the motion’s pipeline of modules
• exit.lua: Handles all exit conditions and behavior

This structure makes the logic easier to follow, easier to test, and dramatically more flexible for future features.

---

📦 Exit Events — A Game-Changer

Alongside the engine overhaul, I introduced a new exit event system.

Instead of forcing every layer of the pipeline to manually bubble up an exit_type, we now use a declarative event-based exit system.

Any part of the engine can now do something like:

events.exit(ctx, motion_state, EXIT_TYPE.EARLY_EXIT)

This cleanly and instantly exits the motion, regardless of where it’s called from.

---

🔍 Why this is powerful:

• Eliminates error-prone nested condition checks
• Makes pipeline modules simpler and more focused
• Opens the door for new event types (e.g. RESTART_PIPELINE, AUTO_SELECT, WAIT_FOR_INPUT, etc.)

---

##🔮 The Future of Events

Right now, the system only supports a handful of exit types like:

• early_exit
• abort
• continue_to_selection

But this system was built with extensibility in mind.
Possible future uses:

• Triggering UI updates from specific modules (events.show_message(...))
• Pausing execution to wait for user input
• Restarting a pipeline with modified state
• Dynamically switching to a fallback motion
• Intercepting with a custom visualizer on error

Think of this as a low-level event bus for motion lifecycle control.

---

##🧼 Cleanup & Performance Wins

This refactor also led to:

• Less duplicated logic
• Reduced state juggling between functions
• Simpler control flow for complex motions

Motions like "repeat previous", "flow chain", and "dot-repeat" now have a cleaner foundation to build on.

---

##🗣️ Let’s Discuss

I’d love your feedback on:

• How this feels as a direction
• Any pain points you’ve hit with motions or exits
• Ideas for new event types or usages

Thanks again for trying out SmartMotion and for all the incredible support so far. This plugin has grown way beyond my original idea, and I can’t wait to share what’s coming next.

— Keenan