Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SplitPane using top_level = true leaves behind ghost space #4984

Open
amanjitsk opened this issue Feb 8, 2024 · 0 comments
Open

SplitPane using top_level = true leaves behind ghost space #4984

amanjitsk opened this issue Feb 8, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@amanjitsk
Copy link

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

  1. Start with a single pane in a tab
|       |
    1
|       |
  1. Create a vertical split (split it bottom)
|   1   |
---------
|   2   |
  1. Split Pane 2 horizontally to the right using the full height i.e.
    `SplitPane({ top_level = true, direction = "Right" })
| 1 |   |
----| 3
| 2 |   |
  1. Trying to split Pane 3 does not work anymore. Furthermore, even
    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)
  2. Closing Pane 3 and 2 now, and repeating Step 2. now results in the
    following layout (unexpected)
| 1 |   |
----|  
| 2 |   |

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

Debug Overlay
wezterm version: 20240208-085947-f671a9ab x86_64-unknown-linux-gnu
Window Environment: X11 bspwm
Lua Version: Lua 5.4
OpenGL: Mesa Intel(R) HD Graphics 520 (SKL GT2) 4.6 (Compatibility Profile) Mesa 23.0.4-0ubuntu1~22.04.1
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
14:20:34.542 ERROR wezterm_gui::spawn > Failed to spawn: split_pane: No space for split!
14:20:35.819 ERROR mux::tab > No space for split!!! SplitDirectionAndSize {
    direction: Vertical,
    first: TerminalSize {
        rows: 11,
        cols: 210,
        pixel_width: 1890,
        pixel_height: 220,
        dpi: 96,
    },
    second: TerminalSize {
        rows: 12,
        cols: 210,
        pixel_width: 1890,
        pixel_height: 240,
        dpi: 96,
    },
} height=24 width=210 top_of_second=12 left_of_second=0 tab_size=TerminalSize { rows: 48, cols: 104, pixel_width: 936, pixel_height: 960, dpi: 96 }
14:20:35.819 ERROR wezterm_gui::spawn > Failed to spawn: split_pane: No space for split!
14:20:37.721 ERROR mux::tab > No space for split!!! SplitDirectionAndSize {
    direction: Horizontal,
    first: TerminalSize {
        rows: 23,
        cols: 104,
        pixel_width: 936,
        pixel_height: 460,
        dpi: 96,
    },
    second: TerminalSize {
        rows: 23,
        cols: 105,
        pixel_width: 945,
        pixel_height: 460,
        dpi: 96,
    },
} height=23 width=210 top_of_second=0 left_of_second=105 tab_size=TerminalSize { rows: 48, cols: 104, pixel_width: 936, pixel_height: 960, dpi: 96 }
14:20:37.722 ERROR wezterm_gui::spawn > Failed to spawn: split_pane: No space for split!
14:27:41.255 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
14:36:43.949 ERROR wezterm_mux_server_impl::local > writing pdu data buffer: Broken pipe (os error 32)
14:37:08.103 ERROR mux::tab > No space for split!!! SplitDirectionAndSize {
    direction: Horizontal,
    first: TerminalSize {
        rows: 25,
        cols: 104,
        pixel_width: 936,
        pixel_height: 500,
        dpi: 96,
    },
    second: TerminalSize {
        rows: 25,
        cols: 105,
        pixel_width: 945,
        pixel_height: 500,
        dpi: 96,
    },
} height=25 width=210 top_of_second=0 left_of_second=105 tab_size=TerminalSize { rows: 50, cols: 104, pixel_width: 936, pixel_height: 1000, dpi: 96 }
14:37:08.104 ERROR wezterm_gui::spawn > Failed to spawn: split_pane: No space for split!
>

Anything else?

No response

@amanjitsk amanjitsk added the bug Something isn't working label Feb 8, 2024
boazy added a commit to boazy/wezterm that referenced this issue Aug 15, 2024
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.
boazy added a commit to boazy/wezterm that referenced this issue Sep 20, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant