no space for new pane with main-horizontal and a few panes

Step 1: Provide a summary of your problem

I created a yaml config with five panes in layout main-horizontal (although main-vertical also breaks). When I tried to run it it failed with the following exception:

Traceback (most recent call last):
  File "/home/abraham/.local/bin/tmuxp", line 8, in <module>
    sys.exit(cli.cli())
  File "/usr/lib/python3.10/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python3.10/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python3.10/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3.10/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3.10/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/usr/lib/python3.10/site-packages/click/decorators.py", line 26, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/abraham/.local/lib/python3.10/site-packages/tmuxp/cli/load.py", line 573, in command_load
    load_workspace(config[-1], **tmux_options)
  File "/home/abraham/.local/lib/python3.10/site-packages/tmuxp/cli/load.py", line 418, in load_workspace
    _load_attached(builder, detached)
  File "/home/abraham/.local/lib/python3.10/site-packages/tmuxp/cli/load.py", line 159, in _load_attached
    builder.build()
  File "/home/abraham/.local/lib/python3.10/site-packages/tmuxp/workspacebuilder.py", line 268, in build
    for p, pconf in self.iter_create_panes(w, wconf):
  File "/home/abraham/.local/lib/python3.10/site-packages/tmuxp/workspacebuilder.py", line 420, in iter_create_panes
    p = w.split_window(
  File "/usr/lib/python3.10/site-packages/libtmux/window.py", line 533, in split_window
    raise exc.LibTmuxException(pane_cmd.stderr, self._info, self.panes)
libtmux.exc.LibTmuxException: (['no space for new pane'], {'session_name': 'foo', 'session_id': '$15', 'window_id': '@36', 'window_name': 'bash', 'window_width': '80', 'window_height': '24', 'window_layout': 'd96b,80x24,0,0,89', 'window_panes': '1', 'window_index': '0', 'window_flags': '*', 'window_active': '1', 'window_bell_flag': '0', 'window_activity_flag': '0', 'window_silence_flag': '0'}, [Pane(%89 Window(@36 0:bash, Session($15 foo))), Pane(%90 Window(@36 0:bash, Session($15 foo))), Pane(%91 Window(@36 0:bash, Session($15 foo))), Pane(%92 Window(@36 0:bash, Session($15 foo)))])

Step 2: Provide tmuxp details

debug-info

also my console window is 213x51

Step 3: Describe the problem:

layout is not loaded, session is partially formed but not attached, exception is thrown.

Steps to reproduce:

I created this minimal config file that reproduces the issue:

session_name: foo
windows:
- focus: 'true'
  layout: main-horizontal
  panes:
    - focus: 'true'
      shell_command:
        - echo 1
    - echo 2
    - echo 3
    - echo 4
    - echo 5

Observed Results:

A python exception

Expected Results:

A nicely built main-horizontal layout

Thoughts

Of course if I build the layout by hand it works, because I'm a human and I know that if I split the same pane over and over again, since every new pane is half the size of the previous one then soon my panes will be too small. So I resize them a little bit before splitting again, then adjust the final size.

Perhaps the algorithm for building the layout could do that. I think it is possible to know the final size of everything just from the layout, the amount of panes and the window size.

Ok it just happened again with a hand-made layout:

layout: 0f12,213x50,0,0[213x39,0,0{142x39,0,0,95,70x39,143,0[70x9,143,0,105,70x9,143,10,108,70x9,143,20,106,70x9,143,30,107]},213x10,0,40{106x10,0,40,101,106x10,107,40,103}]

@categulario

@categulario Can you give a screenshot of this?

perhaps a video recording? (mp4 and webm work on github now)

Here it is

vokoscreenNG-2022-08-26_18-58-32.recortado.mp4

@categulario

@categulario This is an interesting one. Makes sense that the screen would run out

Start a tmux and just paste tmux split-window. It will eventually give you no space for new pane

I suppose a few things we could try is:

A larger default-size, and/or
After each time w.split_window() is ran, try to run w.select_layout(wconf.get("layout", "even-vertical"))

Another thing is we could make it so individual pane commands could control how they're split in greater detail (and explicitly choose to select_layout between creating panes/splitting windows).

I'm experiencing possibly the same issue with a custom layout.

Some additional data points:
The issue started after an update (Archlinux packages tmuxp 0.13.0-1 -> 0.13.1-1 and python-libtmux 0.14.0-1 to 0.14.2-1)
I have not touched my configuration, it worked before the update, it breaks with the new version, a downgrade "fixed" the issue for me.
I also ran tmuxp freeze again, thinking maybe the layout definition changed, and remaking the configuration might fix it. It did not.

What I notice in the error message is that it seems to detect 'window_width': '80', 'window_height': '24' but my default terminal size is 150x75.
Here's a slightly redacted configuration tmuxp.json

It seems to me that the addition of a default size of 80x24 in #793 might have caused this. The layout string (at least for these custom layouts) includes the required window size. Maybe that can be used instead of a default size? Or the minimum required size could be pre-calculated from the layout string (and the number of panes in the window)?

Let me know if I can provide more information.

@jgottfried

@jgottfried Thank you for this feedback as well

The issue started after an update (Archlinux packages tmuxp 0.13.0-1 -> 0.13.1-1 and python-libtmux 0.14.0-1 to 0.14.2-1)

v1.13.1: diff

This is the particular area of code in question I think would be of conflict (as you said, from #793):

v1.13.0...v1.13.1#diff-9316655a97cbe443559ee45c1b1fa26bfa86e314210653806ce215702a956931R221-L425

Let me know if I can provide more information.

@jgottfried If you had a video of the behavior in 1.13.0 vs 1.13.1, that'd be a dream.

Also, does this look like a fair YAML representation of it?

Details

---
session_name: main
windows:
- layout: c1bd,150x74,0,0,0
  panes:
  - shell_command: top
  start_directory: "~"
  window_name: top
- focus: 'true'
  start_directory: "~/Projects/flask-project"
  layout: 5313,150x74,0,0[150x2,0,0,1,150x17,0,3{75x17,0,3,2,74x17,76,3,3},150x17,0,21,4,150x17,0,39,5,150x17,0,57,6]
  options:
    automatic-rename: 'off'
  panes:
  - shell_command:
    - echo celery
  - shell_command:
    - echo gunicorn
  - shell_command:
    - echo monitoring
  - shell_command:
    - echo python
  - shell_command:
    - echo process
  - focus: 'true'
    shell_command:
    - echo flask shell
  window_name: flask-project
- layout: c1c4,150x74,0,0,7
  options: {}
  panes:
  - shell_command:
  start_directory: "~"
  window_name: misc

What I notice in the error message is that it seems to detect 'window_width': '80', 'window_height': '24' but my default terminal size is 150x75.

@categulario @jgottfried What if we allowed default_size to be set / disabled in the config file?

@jgottfried

2022-08-28.19-12-46.mp4

Video shows the configuration file, it working in v1.13.0, upgrade to 1.13.1, the error message, downgrade to 1.13.0 and it working again.

@jgottfried What if we allowed default_size to be set / disabled in the config file?

That could work. It might even be necessary for the even spacing layouts. And if that is the quickest way to fix this issue, that would be great.

[Edited to make preview show]

@jgottfried

@jgottfried Thank you very much! (you can add a newline before your .mp4 file and it'll show a video preview by the way)

Here is the issue

Right now: WorkspaceBuilder's behavior with setting layouts and incrementally building out panes is ambiguous - the behavior is undefined. That's probably a good thing for now - we have time to adapt to real world cases and avoid defining it too soon.

In 1.13.1, we set a default size, but we also moved around calls to window.select_layout(), which shuffles around the dimensions of the panes.

What I propose is:

we allow setting default-size (perhaps to null to not set it, or a custom value), that's only fair
we consider adding w.select_layout() to how it was before, or use it more aggressively before running split_window()s

@categulario

@categulario @jgottfried

Do your .tmux.conf files have a default-size?
For the configs having the no space for new pane issue, do you usually launch those when tmux server is already running?

@nvasilas

@nvasilas CC'ing you on this and #806. There seems to be a side effect from #793's changes

P.S. it works fine for me, but for some configurations with a lot of panes, it seems to run out of spaces while building

Do your .tmux.conf files have a default-size?

Nope

For the configs having the no space for new pane issue, do you usually launch those when tmux server is already running?

sometimes

I am seeing the same bug w tmuxp 1.13.1, libtmux 0.14.2. If I drop to three panes it works but any higher and it breaks with the "no space for new pane" error message.

I am having same issue

Traceback (most recent call last):
  File "/usr/local/bin/tmuxp", line 8, in <module>
    sys.exit(cli.cli())
  File "/usr/local/Cellar/tmuxp/1.13.1/libexec/lib/python3.10/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/Cellar/tmuxp/1.13.1/libexec/lib/python3.10/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/usr/local/Cellar/tmuxp/1.13.1/libexec/lib/python3.10/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/Cellar/tmuxp/1.13.1/libexec/lib/python3.10/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/Cellar/tmuxp/1.13.1/libexec/lib/python3.10/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/Cellar/tmuxp/1.13.1/libexec/lib/python3.10/site-packages/click/decorators.py", line 26, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/Cellar/tmuxp/1.13.1/libexec/lib/python3.10/site-packages/tmuxp/cli/load.py", line 573, in command_load
    load_workspace(config[-1], **tmux_options)
  File "/usr/local/Cellar/tmuxp/1.13.1/libexec/lib/python3.10/site-packages/tmuxp/cli/load.py", line 418, in load_workspace
    _load_attached(builder, detached)
  File "/usr/local/Cellar/tmuxp/1.13.1/libexec/lib/python3.10/site-packages/tmuxp/cli/load.py", line 159, in _load_attached
    builder.build()
  File "/usr/local/Cellar/tmuxp/1.13.1/libexec/lib/python3.10/site-packages/tmuxp/workspacebuilder.py", line 268, in build
    for p, pconf in self.iter_create_panes(w, wconf):
  File "/usr/local/Cellar/tmuxp/1.13.1/libexec/lib/python3.10/site-packages/tmuxp/workspacebuilder.py", line 420, in iter_create_panes
    p = w.split_window(
  File "/usr/local/Cellar/tmuxp/1.13.1/libexec/lib/python3.10/site-packages/libtmux/window.py", line 533, in split_window
    raise exc.LibTmuxException(pane_cmd.stderr, self._info, self.panes)
libtmux.exc.LibTmuxException: (['no space for new pane'], {'session_name': 'tss', 'session_id': '$22', 'window_id': '@44', 'window_name': 'tmux', 'window_width': '80', 'window_height': '24', 'window_layout': 'ace7,80x24,0,0,108', 'window_panes': '1', 'window_index': '0', 'window_flags': '*', 'window_active': '1', 'window_bell_flag': '0', 'window_activity_flag': '0', 'window_silence_flag': '0'}, [Pane(%108 Window(@44 0:tmux, Session($22 tss))), Pane(%109 Window(@44 0:tmux, Session($22 tss))), Pane(%110 Window(@44 0:tmux, Session($22 tss))), Pane(%111 Window(@44 0:tmux, Session($22 tss)))])

I did not had any ~/.tmux.conf had to create from tmux show -g | > location

it have default size as 80x24 changed it didn't helped. removed it didn't helped

Tried Tiled, main-horizontal, custom

Tmux file:

session_name: test
windows:
  - windows-name: dev
    layout: 75b9,238x60,0,0[238x14,0,0{119x14,0,0,75,118x14,120,0,85},238x14,0,15,82,238x15,0,30,84,238x14,0,46,83]
    shell_command_before:
      - cd ../../
      - bash
    panes:
      - shell_command:
        - echo hello
      - shell_command:
        - echo hello
      - shell_command:
        - echo hello
      - shell_command:
        - echo hello
      - shell_command:
        - echo hello

I was getting a very similar (identical?) error...

...but now that I have an existing session running, these no space for new pane errors are gone and I'm able to do tmuxp load test to successfully load the following file:

 session_name: test
windows:
  - windows-name: dev
    layout: 75b9,238x60,0,0[238x14,0,0{119x14,0,0,75,118x14,120,0,85},238x14,0,15,82,238x15,0,30,84,238x14,0,46,83]
    panes:
      - shell_command:
        - echo hello
      - shell_command:
        - echo hello
      - shell_command:
        - echo hello
      - shell_command:
        - echo hello
      - shell_command:
        - echo hello

as well as my other more complex yml file.

Are other people experiencing this issue only when there are no existing tmux sessions?

PS:

Can you please tell me. what do you mean by existing session?

When tmux is running and you're using or "attached" to it, you're in a tmux "session" :)

its tmuxp 1.31.1 libtmux 0.14.2

Oh yeah, version numbers, always important...

libtmux  0.14.2
tmuxp    1.13.1

do tmux ls and it will show existing sessions (which I believe are technically on tmux's default server, as you can have multiple servers, apparently, I think).

If no sessions exist, doing tmux ls will say something about "no tmux server could be found" or somthing.

Do you follow?

So...

If you have no sessions running at all, then do tmux that will create a new session, so now you have a session running and tmux ls would verify that. Then detach from that session. THEN create new session via tmuxp load test.... and does that work now?

If so... that should narrow down "when" this problem occurs... I think... maybe?

no it does not work :(

For the moment the workaround is:

If on 1.13.1: launch less windows in your session
Use 1.13.0

If I write a "fix" - I use quotes because the behavior is undefined as of now [1]😆 - I will need to take time to write tests myself and ensure old behavior isn't broken.

PRs are welcome in the mean time

[1] And if I define behavior, we need find a way to satisfy valid, common usage cases in a good way.

P.S. In the background, I am taking time to improve our test infrastructure to make sure issues like this don't happen again.

@ahillio

Are other people experiencing this issue only when there are no existing tmux sessions?

@ahillio I believe that's why it happens. The tmux server's dimensions are small in 1.13.1, since it'll only be 80x24 until your client connects to tmux. (This is how I believe it works, I would need to look closer at tmux(1) proper to be sure)

I will try to release a patch / PR tomorrow for the thread to test

And thank you for the details and the libtmux / tmux version in here (re: #800 (comment))

@Haider-Ali-DS Welcome Haider! Thanks for the details confirming it is v1.13.1 as well (re: #800 (comment)).

If you are around this weekend I will release a new version of tmuxp for the thread to test

@categulario

@categulario @jgottfried

re: #800 (comment)

Can you try to run tmuxp ls to see if it show any tmux clients connected before you run the issue is recreated? My assumption is there won't be any clients connected yet

Oh... actually... I'm experiencing this when there are existing sessions already. I'm not sure what caused it to work previously but now detaching from my session and running tmuxp load test results in error. A new session gets create but it doesn't attach to it.

pip install -Iv tmuxp==1.13.0 results in a working-as-expected installation. I'm just started with tmuxp, coming from tmuxinator, and I'm very pleased to have this working :)

Oh interesting! Switching back to 1.13.1... having existing sessions is not what caused it to work, being attached to those sessions (or just one) caused it to work. If sessions exist but I'm not attached to them (like if I'm doing this in a single terminal) then the error persists, but if I have multiple terminals open and one of them has an attached tmux session then tmuxp load test works as expected.

@ApexWeed

@ApexWeed in re: #806 (comment) / #806, this is the main thread for the issue I think yours duplicates

@ahillio

@ahillio @Haider-Ali-DS @categulario @jgottfried

Using v1.13.1, If you add an options or global_options with default-size: 800x600, is anything different? (see docs here)

e.g.

# the rest of your config
options:
  default-size: 800x600

or

# the rest of your config
global_options:
  default-size: 800x600

Yes…

test.yml:

session_name: test
windows:
   - windows-name: dev
     layout: 75b9,238x60,0,0[238x14,0,0{119x14,0,0,75,118x14,120,0,85},238x14,0,15,82,238x15,0,30,84,238x14,0,46,83]
     panes:
       - shell_command:
         - echo hello
       - shell_command:
         - echo hello
       - shell_command:
         - echo hello
       - shell_command:
         - echo hello
       - shell_command:
         - echo hello
options:
   default-size: 800x600

and tmuxp load test works (assuming tmuxp -V is accurately showing the correct versions every time I install a different version, I'm new to pip and not sure if there's any caching weirdness etc but there doesn't seem to be [it always impresses me when package managers don't break]) with 1.13.1.

@ahillio

@ahillio Thank you! I will release a patch for this.

and tmuxp load test works (assuming tmuxp -V is accurately showing the correct versions every time I install a different version, I'm new to pip and not sure if there's any caching weirdness etc but there doesn't seem to be [it always impresses me when package managers don't break]) with 1.13.1.

Yes you can trust tmuxp -V

@ahillio

@ahillio @Haider-Ali-DS @categulario @jgottfried

Using v1.13.1, If you add an options or global_options with default-size: 800x600, is anything different? (see docs here)

e.g.
# the rest of your config
options:
  default-size: 800x600
or
# the rest of your config
global_options:
  default-size: 800x600

yes, thank you it showed no error this time.

Navigation Menu

Repository navigation

no space for new pane with main-horizontal and a few panes #800

Step 1: Provide a summary of your problem

Step 2: Provide tmuxp details

Step 3: Describe the problem:

Steps to reproduce:

Observed Results:

Expected Results:

Thoughts

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

📋 Server Request & Proxy Logs

⚙️ Pengaturan Proxy Target

no space for new pane with main-horizontal and a few panes #800

Description

Step 1: Provide a summary of your problem

Step 2: Provide tmuxp details

Step 3: Describe the problem:

Steps to reproduce:

Observed Results:

Expected Results:

Thoughts

Activity

categulario commented on Aug 26, 2022

tony commented on Aug 26, 2022

categulario commented on Aug 26, 2022

tony commented on Aug 26, 2022

jgottfried commented on Aug 28, 2022

tony commented on Aug 28, 2022

jgottfried commented on Aug 28, 2022

tony commented on Aug 28, 2022

tony commented on Aug 28, 2022

tony commented on Aug 29, 2022

tony commented on Aug 29, 2022

categulario commented on Aug 29, 2022

holybit commented on Sep 7, 2022

haider-rs commented on Sep 8, 2022

ahillio commented on Sep 8, 2022

3 remaining items

haider-rs commented on Sep 8, 2022

ahillio commented on Sep 8, 2022

haider-rs commented on Sep 9, 2022

tony commented on Sep 9, 2022

tony commented on Sep 9, 2022

tony commented on Sep 9, 2022

tony commented on Sep 9, 2022

ahillio commented on Sep 10, 2022

ahillio commented on Sep 10, 2022

ahillio commented on Sep 10, 2022

tony commented on Sep 10, 2022

tony commented on Sep 10, 2022

ahillio commented on Sep 10, 2022

tony commented on Sep 10, 2022

haider-rs commented on Sep 11, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions