Nice work! Demo video looks good.

it would be nice to have a border for this floating pane

Updated with border.

Configs:

config.float_pane_padding = {
  left = '10%',
  right = '10%',
  top = '10%',
  bottom = '10%',
}

config.float_pane_border = {
  left_width = '0.5cell',
  right_width = '0.5cell',
  bottom_height = '0.25cell',
  top_height = '0.25cell',
  left_color = '#665c54',
  right_color = '#665c54',
  bottom_color = '#665c54',
  top_color = '#665c54',
}

I think this is ready to be reviewed now.

Thanks a lot, this is the one feature I've been missing since transition from tmux to wezterm mux 🙏🏼

Tested this and it works really well, just commenting with some small issues I've seen:

• The float panes all open in my home directory instead of the current directory like split panes and new tabs do
• The pane selection UI is hard to read if having no split panes and one floating since the underlying pane and the float panes letter overlaps
• If moving all non floating panes to a new tab or window the floating pane is shown on an otherwise invisible window, would be nice to either disallow this or de-float the floating pane

A very nice action to have but definitely not required for this to be super useful on its own, is to be able to toggle the floating status of a pane so you can transition a floating pane to a split pane and vice verse.

@Pajn I think I have the working directory issue fixed now.

For the pane selection my intention was to treat the float like a overlay and turn any selection operations into no-ops and prevent the mouse from selecting a pane (I think there were some scenarios that I missed like the selection UI). I pushed an update that I think turn those into nops now. This may not be the right strategy, is there a scenario where you would want to be able to select/interact with the panes underneath the float?

I think I have it updated so that closing the pane underneath the float is blocked now. Which I think will prevent the scenario where only the float is showing.

I tried out being able to move the float to a split today. It seemed to work, I pushed it to this branch if you want to give it a try. I didn't want to include it in this pull request to keep the scope down.
https://github.com/e82eric/wezterm/tree/move-float-to-split

This is what it looked like.

Wow! I was just starting to familiarize myself with the code to see if I could help but not at that speed :)
Very quick testing have all the issues I experienced fixed.

This may not be the right strategy, is there a scenario where you would want to be able to select/interact with the panes underneath the float?

I was mostly just trying to break it to see where the limitations where. The one possible usecase I can see is to move one background pane to another tab/window if you need access to it after realizing the float pane was longer lived than you intended. However I think that's better solved by being able to transition the float pane to a split anyway. And disabling those actions when in a float definitely avoids a whole class of potential problems.

I didn't want to include it in this pull request to keep the scope down.

Totes! I was just excited. Thanks a lot for the branch though, will definitely start playing with it.
And if there is anything I can do to help get this merged, let me know.

i really like the work man, good stuff been wanting this feature, as im coming from zellij that has a really nice implementation of floating panes

Thanks! updated

What is the status of this PR? Really great feature&work btw!

Thanks! I think this is more or less still pending review. I am happy to put in the work to get this across the the finish line, but don't want bug Wez about it, I am sure he has a million priorities. In the mean time if anyone wants to give it a try and notice any issues or want to review the code, I can work through those.

Sure. I am on windows as well, by the way.

config.floating_pane_padding = {
  left = '5%',
  right = '5%',
  top = '10%',
  bottom = '10%',
}

config.floating_pane_border = {
  left_width = '0.2cell',
  right_width = '0.2cell',
  bottom_height = '0.10cell',
  top_height = '0.10cell',
  left_color = '#cdd6f4',
  right_color = '#cdd6f4',
  bottom_color = '#cdd6f4',
  top_color = '#cdd6f4',
}

While I have your time as well, I am trying to bind CTRL+` to open a floating pane with the default shell, and then when pressed again it would toggle visibility (I imagine toggle preserves the scrollback/history). How would I go about doing this, where its created once and then subsequent presses toggle the visibility, and where there might be other floating panes active as well (If the shell pane is toggle invisible then it should be brought to the foreground among floating panes, an when toggled again I should see any other panes behind it)? Thanks!

@RoloEdits I think I found the issue, if you get a chance can you try the latest commit?

I think this is what you are looking for.

{ key = '`', mods = 'CTRL', action = act.ToggleFloatingPane }

@e82eric Yep, that fixed it!

And that key toggle is exactly what I was looking for.

Thanks for the help and this feature, its working great.

One thing im not sure is functioning correctly or if its a bug is what pane is shown after a floating pane is closed. For example, if I have a "persistent" floating terminal hidden, for example to edit code but want to keep the state around, and then bring up lazygit in a newly spawned floating window, when I quit out of that, the expectation is that I will be back in my text editor, the last pane I was in. But when lazygit closes, the supposed to be hidden floating terminal pane shows up and captures the cursor, needing me to hide it again.

@RoloEdits I just pushed an update so that when you close a floating pane it will show the regular pane beneath instead of showing the next floating pane.

Is anyone here using Helix?

It has an option to enable auto save:

[editor]
auto-save=true

I've just noticed that the auto-save feature doesn't trigger when switching to a floating pane. However, it works correctly when switching to a normal pane.

Could it be that the focus events aren't emitted in this case?

@e82eric my sincere congratulations and thank you for your significant work! I hope it gets reviewed soon :)

Is anyone here using Helix?

It has an option to enable auto save:

[editor]
auto-save=true

I've just noticed that the auto-save feature doesn't trigger when switching to a floating pane. However, it works correctly when switching to a normal pane.

Could it be that the focus events aren't emitted in this case?

@quantonganh if you get a chance could try the latest commit. I think I found the issue

@quantonganh if you get a chance could try the latest commit. I think I found the issue

@e82eric Thank you for your quick fix. I confirm that it's working fine now.

Hey ya'll I'm probably WAY off but besides the floating part I think this can be done with

--mini term
	{
		key = "k",
		mods = "CMD",
		action = wezterm.action_callback(function(_, pane)
			local tab = pane:tab()
			local panes = tab:panes_with_info()
			if #panes == 1 then
				pane:split({
					direction = "Right",
					size = 0.4,
				})
			elseif not panes[1].is_zoomed then
				panes[1].pane:activate()
				tab:set_zoomed(true)
			elseif panes[1].is_zoomed then
				tab:set_zoomed(false)
				panes[2].pane:activate()
			end
		end),
	}

along with Dim inactive panes

config.inactive_pane_hsb = {
	saturation = 1,
	brightness = 0.24,
}

Hey @e82eric thanks for your hard work. But do you think it would be possible to make this a plugin for wezterm, while your waiting?

@Icvza I've used a very similar approach for months, but pane zoom messes up the sizing of my neovim splits, because the panes' sizes change. As I usually use just vertical splits, it can be countered by spawning a pane on the bottom and zooming that, but it's still not ideal.

I've been test-driving this branch and it's great. Great work, @e82eric!

... but pane zoom messes up the sizing of my neovim splits, because the panes' sizes change. As I usually use just vertical splits, it can be countered by spawning a pane on the bottom and zooming that, but it's still not ideal.

@oskarkook kwkarlwang/bufresize.nvim might solve the nvim pane sizing issue you're having. Have been using this with wezterm splits for a while.

@e82eric Since there are multiple floating panes in each tab, but only one can be rendered (if we choose to show), I think it would be useful to have an option to switch between floating panes or create a new floating pane in the current tab.

This can be done by adding FLOATING_PANES in ShowLauncherArgs flags, similar to WORKSPACES

@mgpinf #5576 (comment)

You can switch between floating panes by using the same keys that are used to activate the left/right pane:

  {
    key = 'h',
    mods = 'ALT',
    action = act.ActivatePaneDirection 'Left',
  },
  {
    key = 'l',
    mods = 'ALT',
    action = act.ActivatePaneDirection 'Right',
  },

@quantonganh Thank you 😄

I think it would be useful to add the below for switching between floating panes in the activate_pane_direction method in mux/src/tab.rs:

• Add PaneDirection::Prev to PaneDirection::Left to switch to previous floating pane
• Add PaneDirection::Next to PaneDirection::Right to switch to next floating pane

Since PaneDirection::Prev and PaneDirection::Next activate panes based on current pane index, and PaneDirection::Left and PaneDirection::Right are used to activate floating panes based on current floating pane index. So adding the above is in line with existing flow.

Wait... closed :( This was an amazing piece of work, thanks @e82eric!

Yes, that could be a huge loss... :(

What happened?