add support for popup window

[prabirshrestha]

tmux recently add popup support. Would be great if wezterm has similar support.

https://blog.meain.io/2020/tmux-flating-scratch-terminal/

Useful when you need to create temporary scratch window such as for fuzzy search, git status and so on. Partially aligns with split window feature request #157.

Might be having something like neovim's multigrid would make it easier to implement. https://neovim.io/doc/user/ui.html#ui-multigrid

[wez]

This feels similar to the existing overlay functionality that powers the launcher menu, tab navigator and copy mode functionality.

It probably wouldn't be that difficult to provide an overlay that can spawn a program; likely a lot easier than the full on split feature.

[malkomalko]

Bumping this up a bit as I find myself wanting this feature. I'm happy to try to take this on as a learning experience if I can be pushed in the right direction.

[wez]

I'd love to see a PR for this... I was eyeing this issue the other day; with the recent changes in the renderer it's now feasible to produce inset overlays similar to what is pictured in the OP, and have them layer over the top of the normal set of panes. Previously, we could only literally render the precise model from the mux into statically allocated quads; we can now dynamically allocate those as needed.

I think all of the difficult parts of this issue are nailing down the precise semantics of how the popup fits into the mux model.

The tmux implementation seems to do something very special with the popup in terms of how it is modeled so there is precedent for something to be awkward(!).

The mux crate in wezterm is responsible for driving the reading and parsing of the output when the corresponding Pane is added to the mux: https://github.com/wez/wezterm/blob/main/mux/src/lib.rs#L398

At a high level what I think is needed is:

• Introduce a popup_pane: Option<Rc<dyn Pane>> field to TermWindow that tracks the popup instance
• Adjust the render logic so that pane rendering can take an arbitrary (x, y) coordinate for the top left of the pane rather than the current assumption based on the tab/PositionedPane information
• At the bottom of the render opengl pass function, if popup_pane is present, call the renderer for it.

The hard parts:

• How do we spawn one of these? wezterm cli spawn-popup seems obvious
• The gui runs the mux protocol and subscribes to mux events to know when to mirror and attach to the mux, but the popup doesn't fit the mux model of Window/Tab/Pane
• Spawning should probably resolve the local Domain from the mux, and then spawn the pane, and then add it to the mux, but not to any Window or Tab. Mux::get_domain_by_name("local") and then Domain::spawn but note that that returns a Tab, which we don't want here. We'll need a way just to spawn the Pane without sticking it into a Tab, or to very quickly take the pane out of the tab and remove the empty tab after we've spawned it (probably not great, but maybe a good starting point for MVP?)
• Should probably introduce a MuxNotification that includes the WindowId and PaneId (and positioning info) for the newly added popup so that the gui layer can bind to it and then setup popup_pane in the TermWindow around here somewhere: https://github.com/wez/wezterm/blob/main/wezterm-gui/src/termwindow/mod.rs#L787
• spawn-popup would need a corresponding new request and response PDU in the codec layer, similar to SpawnV2, and support in the CLI itself similar to this

The tmux issue seemed to have some support for arbitrary/static text in the popup, but it looked like that got simplified away later in the issue. I'm generally in favor of running a command in the popup, but not so much for arbitrary/static text showing up there.

Defining how the mouse interacts with the popup is another tricky-ish area: right now there's a lot of math coupled between the renderer and mouse, but ab8c8dc introduces a way to de-couple that and make it a bit easier to route the mouse to the right place. You could punt on that for an MVP if you don't allow for an inset popup and instead make it fill the window space, then all the math would be unchanged and you'd simply route the events to the popup rather than the active pane/overlay that they currently use.

Defining how the keys work with the popup is also important: it sounded like tmux had some special rules for that. There should probably a key assignment that explicitly kills a popup so that there is a sane way to get out of it, but otherwise, it should pretty easy to simply route key presses to the popup pane; the key handling logic already does this sort of thing for the active pane/overlay, so it should be a fairly contained change.

[malkomalko]

Super helpful and gives me a good starting point to give something a go. I'll try to start on something after hours later this week. I'll more than likely open up a DRAFT WIP PR sooner than later to see if I'm totally missing the mark.

I think for first approach we keep things as simple as possible:

• wezterm cli spawn-popup ✅

• We'll need a way just to spawn the Pane without sticking it into a Tab, or to very quickly take the pane out of the tab and remove the empty tab after we've spawned it (probably not great, but maybe a good starting point for MVP?)

  • I like the idea of removing the Pane from the tab, and then removing the empty tab for MVP. This is more than likely in my capabilities jumping into this type of feature on this project ATM anyway.

• I'm generally in favor of running a command in the popup, but not so much for arbitrary/static text showing up there.

  • Agreed

• You could punt on that for an MVP if you don't allow for an inset popup and instead make it fill the window space

  • 100% for MVP. I think insetting/handling the mouse is a great next step.
• On how keys work in the popup, I like the specific key assignment (configurable?) to kill a popup.

[JoyceBabu]

The following article mentions an interesting use case for tmux popups. I never got around to trying it, but had it bookmarked for later.

https://blog.meain.io/2020/tmux-flating-scratch-terminal/

Killing a popup shouldn't be the only way to close a popup, there are cases where we need to hide it temporarily. It would be nice if you could expose actions for creating/hiding/opening/killing popup, that can be assigned to custom key bindings.

[mborejdo]

I also love the idea of having popups and probably a way to control positioning etc. I just came across https://fig.io/ which could take this to the next level ;-)

[cd-a]

Was there a reason the PR in #1059 was abandoned? This is such a useful feature

[mrjones2014]

This really the only thing making me hesitate to drop tmux for wezterm's multiplexer 🤔

[happenslol]

I'm interested in working on this. @malkomalko did you ever consider picking this back up, and would it be fine if I used your prior work as a starting point?

[mrjones2014]

@happenslol I'd be happy to help create a PR for this with you if you'd like to work together over a weekend or something

[happenslol]

Sounds cool, I would like that! What's your preferred method of communication? Let's pick this up somewhere else so we don't spam the thread here :-)

[mrjones2014]

If you have Matrix, you can message me at @mrjones2014:matrix.org (GitHub should make a Direct Messages system 😁)

[mrjones2014]

I tried starting from the PR that was closed but it seems like a lot of it doesn't apply anymore.

[protiumx]

Hi @wez is there any way to fund/sponsor this feat request?

[wez]

@protiumx yeah, if you take a look at my GH sponsors page at the one-time amounts: https://github.com/sponsors/wez?frequency=one-time&sponsor=wez
I would classify this as a medium-to-large-sized effort due to the number of layers it crosses and how long I think it will take to build it out. I don't expect that a single individual will be willing to cover that cost though. As an alternative, if we can reach 1000 monthly sponsors at the current average monthly subscription amount, that will help me justify spending more sustained time and allow me to block out the time for this feature.

[mjs]

It looks like #5576 is pretty close now?