Popup on native remote host

[adamcstephens]

I have the below binding for a popup window. It works well locally, or when ssh+attach. Unfortunately, when using native remote hosts it can't be used even though it's defined on both local and remote hosts. I get the error A popup command works only in a session on this machine. Is there any way I can map this binding to allow it to run on a remote host when using native remote sessions?

[[keybindings.command]]
key = 'super+p'
type = 'popup'
command = '~/.dotfiles/bin/prj'
width = '40%'
height = '40%'

[aashish254]

this one is by design rather than a bug. a popup entry gets opened through the local daemon socket, which does not own a session on another machine, so the binding is refused with that message whenever you are attached to a remote host. the keybindings docs say the same: in a session on a different machine a scratch or popup entry does not run.

the closest thing that does what you want is type = 'pane'. a pane entry runs on the machine of the session, so with native remote attach your ~/.dotfiles/bin/prj would run on the remote host in a pane next to the focused one and close when it exits. width and height only apply to popup and scratch so you can drop those two lines.

so change the entry to type = 'pane' and keep the rest as is. you lose the floating popup but the command runs on the remote host either way.

[adamcstephens]

Seems an odd distinction to me that a popup can't be used remotely, but a standard pane can. Like why is the popup unique? I would have expected it to be just like a pane, but with a different location.

[aashish254]

fair question. it is not the popup ui that is special, it is which daemon each entry talks to.

a popup entry asks the daemon on your local machine to open it, through the local verb socket. that daemon only knows about local sessions. when you are attached to a remote host your session lives in the remote daemon, so the local one has nothing to open the popup in and the binding is refused before it even tries.

a pane entry goes the other way. it asks the session's own daemon through the connection you already have open, which is the remote daemon during a remote attach. so the pane just lands wherever the session lives.

so the distinction is really local daemon versus session daemon. making popups work remotely would mean proxying that popup request through to the remote daemon, which is doable but nobody has built it. the pane path already had that plumbing, which is why it works.

[Gaurav-Gosain]

Thanks @aashish254, that is exactly right for today, and type = 'pane' is the best workaround: it runs on the machine of the session, so prj runs on the remote host.

@adamcstephens I would still like popups to work on a native remote session, because a popup is the nicer fit for a picker like prj. I am going to make a popup entry open on the machine that owns the session, the same way a pane entry already does. I will post here when it lands.

[Gaurav-Gosain]

@adamcstephens this is in main now (#667). A popup or scratch entry now opens on the machine that holds the session, so your super+p binding runs ~/.dotfiles/bin/prj on the remote host when you are attached natively, at the size you set. The far machine needs open in the allow list for this machine; if it is missing, the toast tells you the exact line to add. It will be in the next release, and building from main has it today.