You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What Operating System(s) are you seeing this problem on?
Linux X11
Which Wayland compositor or X11 Window manager(s) are you using?
bspwm w/ picom
WezTerm version
wezterm 20240208-085947-f671a9ab
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
When splitting across the full width (/length) using SplitPane({ top_level = true }), it causes the next call to SplitPane to fail, and even with the pane closed (this is the same bug reported in #2579), it seems that the space is still occupied by the now closed pane (created using top_level = true).
To Reproduce
Start with a single pane in a tab
| |
1
| |
Create a vertical split (split it bottom)
| 1 |
---------
| 2 |
Split Pane 2 horizontally to the right using the full height i.e.
`SplitPane({ top_level = true, direction = "Right" })
When there is more than one pane in the tab, the tab.resize() is
called and the tab resize logic is reused to correctly resize all the
panes in the tab before adding the new pane split, so the new split
pane will not overwrite any existing pane.
The issue seems to be that after this resize, the tab "remembers" its
new size, and when the new split pane is closed, the tab is left with
ghost space which cannot be reused.
The fix is quite simple: we just need to immediately resize the tab
back to its original proportions. Since the underlying panes have
already been resized by tab.resize(), we don't need to keep the
restricted tab size.
When there is more than one pane in the tab, the tab.resize() is
called and the tab resize logic is reused to correctly resize all the
panes in the tab before adding the new pane split, so the new split
pane will not overwrite any existing pane.
The issue seems to be that after this resize, the tab "remembers" its
new size, and when the new split pane is closed, the tab is left with
ghost space which cannot be reused.
The fix is quite simple: we just need to immediately resize the tab
back to its original proportions. Since the underlying panes have
already been resized by tab.resize(), we don't need to keep the
restricted tab size.
What Operating System(s) are you seeing this problem on?
Linux X11
Which Wayland compositor or X11 Window manager(s) are you using?
bspwm w/ picom
WezTerm version
wezterm 20240208-085947-f671a9ab
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
When splitting across the full width (/length) using
SplitPane({ top_level = true })
, it causes the next call toSplitPane
to fail, and even with the pane closed (this is the same bug reported in #2579), it seems that the space is still occupied by the now closed pane (created using top_level = true).To Reproduce
tab
`SplitPane({ top_level = true, direction = "Right" })
if Pane 3 is closed, splitting Pane 1 or 2 does not work either
(see Split created with top_level=true cannot be split any further if started from "non top-level split" #2579)
following layout (unexpected)
with the space previously occupied by Pane 3 still empty.
Configuration
no config
Expected Behavior
Step 5. should result in a layout like Step 2., but the space previously occupied by a full-width (/height) pane remains occupied.
Logs
Anything else?
No response
The text was updated successfully, but these errors were encountered: