Emit from cli

[rosshadden]

Maybe there is a way to do this already that I couldn't find, but it would be a great addition to allow emitting events from the CLI.

Something like this:

wezterm cli emit <event> ...<args>

# emits "lol" event
wezterm cli emit lol

# emits "foo" event with "bar" and "baz" positional arguments
wezterm cli emit foo bar baz

[wez]

There's a bit of nuance to this, similar to focusing-a-pane-via-the-CLI discussion/monologue in #1531. A multiplexer server may have multiple clients connected from multiple locations, so this sort of event emission should probably have a way to specify which client(s) should receive that message in case the event handler that a user has configured is not "idempotent" or is otherwise dangerous/risky to repeat on multiple machines at once.

Passing arbitrary arguments isn't directly compatible with EmitEvent, which is also is only applicable to GUI clients.

What are you planning to do with this functionality? Does it make sense to only allow it to reach a gui client if it is present?

[rosshadden]

Yes, what you proposed should work perfectly and would be a great solution!

For our purposes, consider fzf to just be a placeholder for "interactive script that results in dumping something to stdout". Could also be a file manager like lf, ranger, nnn, etc. Or really even an editor, specifically something like moreutils' vipe which opens an editor and outputs the contents of the written buffer to stdout. Until what you are proposing, I believe such workflows are only possible with non-interactive scripts.

This is a wezterm mapping I have that does pretty much exactly what you are talking about but for a non-interactive script that doesn't need its own pane split. It runs a command, gets the result, and runs pane:paste to send it into the current pane when done (specifically it does what <alt-.> does in bash, zsh, and other shells). Your proposition + #888 would let us do this same kind of thing in more complicated scenarios.

	{
		-- type last arg from most recent command
		mods = "LEADER", key = ".",
		action = wezterm.action_callback(function(win, pane)
			local _, arg, _ = wezterm.run_child_process({ "nu", "-c", "last-arg" })
			pane:paste(arg)
		end)
	},

[wez]

I just pushed b6d121d for sending input to a pane which might help you eliminate the xdotool dep you mentioned in the nushell issue you linked.
I need to think about the other stuff a bit: plumbing things through for that is potentially quite tricky.

[wez]

I think the changes to support what I suggested above are pretty large... however, I think you can script around this if you're willing to write a helper script and constrain this stuff to only on the local machine. The suggestion is:

• man 1 mkfifo and man 3 mkfifo to read up on named pipes.
• Write a script that goes something like this untested suggestion:

#!/bin/bash

# Make some pipes for stdin, stdout
UNIQUE=$(uuidgen)
mkfifo /tmp/$UNIQUE-{stdin,stdout}

# Start the desired program, running it via the shell so that we can redirect its stdio to our pipes.
# Despite having the redirection, it should still be attached to the pty and work interactively.
wezterm cli spawn -- bash -c "whatever < /tmp/$UNIQUE-stdin > /tmp/$UNIQUE-stdout"

# This bit might have to be async wrt. to reading stdout below to avoid blocking with
# large amounts of data
( cat - > /tmp/$UNIQUE-stdin ; rm /tmp/$UNIQUE-stdin ) &

# Block until we've read the output
cat /tmp/$UNIQUE-stdout
rm /tmp/$UNIQUE-stdout

[rosshadden]

Yeah I think the commit you pushed may be enough for me to do everything I was asking about here, but I haven't rolled up my sleeves to try to confirm yet.

[rosshadden]

I have been working at this for a couple days now and not yet had luck. I was holding off on replying until I better understood what is wrong so I may be as helpful as possible.

I think the best I can put it is that some permutation of pane:pane_id, wezterm cli send-text --pane-id, and wezterm cli list are wrong or in disagreement. The PANEID output by the list is very different from the one available inside an action callback. In fact I believe I have only ever seen the pane:pane_id() be 1.

I believe that is why everything I have been trying with the new command you added has been failing. I am trying to use chains of commands in SplitVertical, os.execute, and other similar functions (specifically ones that run on the wezterm domain in question and not on the parent domain, as opposed to run_child_process and background_child_process). The goal of these chains is ultimately to take text (retrieved from an interactive script, as discussed, though that's not the defining factor) and use them as an argument to the new wezterm cli send-text command.

[rosshadden]

This would allow us to do things like have an action make a split to open, say, fzf with some things piped to it, choose a result, and emit the result (and originating pane) as an event.

# emits "split-response" event with pane ID and result of an `fzf` query or whatever
wezterm cli emit split-response 4 "./some/path/to/file.whatever"

-- wezterm.lua
wezterm.on("split-response", function(win, pane, paneID, result)
  window:perform_action(
    wezterm.action_callback(function(_, pane)
      pane:paste(result)
    end,
    paneID
  )
end)

[wez]

I'm not 100% sure I'm following this example; can you spell it out to me a bit more clearly?
I think you're saying that want to trigger (via the cli) opening a pane with fzf running inside it and then you want to take the final selection output from fzf in that pane and consume it from the point where the original trigger was invoked?

[rosshadden]

Yes exactly what you said. I more details and examples as a response to your comment above.

[wez]

I can see you wrote some more context above: reading now!