[FEAT] Support for sending keystrokes to the target

[jxyyz]

Problem

I'm using Claude Code with vim mode. So it requires pressing i for starting INSERT mode before providing any text/prompt.

I believe there's no easy way to send keystrokes before or after pasting text to a target within wiremux's API.

This also applies to other TUI apps - anything where you need to prepare the target's state before pasting (enter insert mode, clear a prompt, etc.) or clean up after (press Escape, submit with a specific key sequence).

Suggestion

NOTE: I'm happy to implement these changes. I'll probably tinker with this in my spare moments anyway to achieve this functionality for my own workflow.

Add keys_before and keys_after fields to SendItem:

---@class wiremux.action.SendItem
---@field value string
---@field label? string
---@field submit? boolean
---@field keys_before? string[]   -- keystrokes to send before pasting
---@field keys_after? string[]    -- keystrokes to send after pasting

The tmux batch per target would be:
a)
keys_before → paste-buffer → keys_after → Enter (if submit).

or b)
keys_before → paste-buffer → Enter (if submit) → keys_after

... not sure which is better.

Of course there are other possible approaches to this problem. I'm open to discuss them.

Usage

-- Send to TUI app in vim mode
wiremux.send({
  value = "explain this code",
  keys_before = { "i" },
  submit = true,
})

-- Or in a send library
wiremux.send({
  { value = "explain {file}", label = "Explain", keys_before = { "i" }, submit = true },
  { value = "review {selection}", label = "Review", keys_before = { "i" }, submit = true },
})

Note: This depends on send_keys being fixed first (see #16 - send_keys hardcoded Enter issue), since the current implementation can't send arbitrary keystrokes.

Future enhancements

Above suggestion is based on existing action.send_keys() in tmux backend implementation.

We can consider these enhancements in the future:

• exposing some sort of action.send_keystrokes (maybe with a better name) in user facing API, to allow users to programmatically achieve more complicated workflows in TUI targets
• allowing users to check if something is happening on the screen (e.g., checking if -- INSERT -- indicator is present in the TUI)
  • I think it can be a good use case for the capture() function from watch.lua

But I think it needs some additional planning and good design decisions, since it will increase the overall complexity of the plugin. And maybe it's not the goal of this project.

[MSmaili]

Thanks for the detailed proposal! I typically add features I use myself since it helps me catch issues early, but I'm
open to adding functionality that benefits others, even if it's complex, as long as we can design it cleanly and is within the scope of what we are doing

Option A makes more sense to me:

keys_before → paste-buffer → keys_after → Enter (if submit)

The send_keys capability would be useful for your use case and others. I need to think through the public API design, though.
My initial thought was to allow tables inside value to mix keys and text, but then we'd need a clear way to
differentiate between send-keys and paste-buffer operations, something that makes sense, which then, when I come back to your proposal, makes more sense probably.

Also need to verify how this translates to Zellij. I don't use zellij personally, but many do, and so far everything has
been convertible (except variables, which I have ideas for). In the future i have a plan to add zellij too #12 .

I'll review the API design and follow up in the coming days. Feel free to experiment on your end. Thanks a lot

[MSmaili]

I think this can be implemented. If I had come up with this idea earlier, I probably wouldn’t have implemented submit at all, only this approach. We can consider deprecating submit in the future and instead placing it under after_keys.

The only thing I’m unsure about is the naming. Should we use keys_before, or go with pre_keys and post_keys instead?
I think pre_keys and post_keys is better? but i do not have a strong opinion.

I can't implement this right now, but I'll do it later. If you have time, feel free to implement. I can check

[jxyyz]

Yes, I agree - pre_keys and post_keys are shorter and more convenient.

I can prototype this on my side and come back with a proposed implementation.

One thing to consider: pre_keys and post_keys are essentially hooks, and I already proposed an on_resolved hook in #14 (comment).

It might make sense to agree on a unified hooks structure in the wiremux.send() signature rather than adding them ad hoc.