layout is broken on 1.3.4

[oblitum]

With this simple configuration now the main window is always with width 2. It doesn't matter whether I set main-pane-width: 160 or not, it's always loaded in a strip of just 2 columns.

session_name: foo
windows:
- layout: main-vertical
  panes:
  - blank
  - blank

I'm using the package from AUR.

Issue is present both in vertical and horizontal layouts.

[oblitum]

There's other strange behavior like character artifacts, etc.

[kageurufu]

Maintainer from the AUR here, I can reproduce without the AUR package, using a clean 3.6.3 virtualenv (--no-site-packages, etc)

tmux 2.6

[tony]

I also get this.

But I think it has more to do with tmux 2.5, than tmuxp.

Can we get a confirmation on tmux versions? Anyone using tmux 2.4 or lower and seeing this?

[oblitum]

I'm also on 2.6. It's what's on ArchLinux repos, and there's no option to downgrade due to dependencies.

[oblitum]

But, by the way, it was fine on 1.3.2 on tmux 2.6.

[kageurufu]

I just build 2.3 through 2.6 on Arch from the ABS, heres the packages AND results for @oblitum's yaml. 2.6 has a 2-wide left pane, while 2.3 to 2.5 all show a 2px wide right pane. This is tmuxp installed in ~/.local with pip install --user tmuxp

tmux-2.3-1-x86_64.pkg.tar.gz

tmux-2.4-1-x86_64.pkg.tar.gz

tmux-2.5-1-x86_64.pkg.tar.gz

tmux-2.6-1-x86_64.pkg.tar.gz

[tony]

• Can I see your options? esp $ tmux showw | grep "main-pane"
• So with other tmuxp versions (e.g. 1.3.3), it's ok?
• what's the expected behavior vs what you get? are all tmux versions showing incorrect results with 1.3.4?

[oblitum]

• Can I see your options? esp $ tmux show | grep "main-pane"
$ tmux show | grep "main-pane" shows nothing for me. tmux show just show status off. In any case, this is my .tmux.conf.

• So with other tmuxp versions (e.g. 1.3.3), it's ok?
  I just tested with 1.3.2 and 1.3.4 lately. Only 1.3.4 presents the issue. It's the first time I see it since I've been using tmuxp from AUR, which has been for good time already, so it can be assumed 1.3.2 and earlier is fine regarding this.

• what's the expected behavior vs what you get?
  The expected behavior is the previous, as it's documented, which are layouts loaded with respected width and height values, custom or default.

• are all tmux versions showing incorrect results with 1.3.4?
  I think @kageurufu did a good job on displaying many tmux versions running tmuxp 1.3.4.

[tony]

The only thing I have to mention is setting a main-pane-height, e.g. https://github.com/tony/tmuxp/blob/master/.tmuxp.yaml#L11

I'm going to check this again in the morning (need z's). We need to check the history to see what caused it.

1.3.2 is OK for sure right? https://tmuxp.git-pull.com/en/latest/history.html There hasn't been many changes between then and 1.3.4... And by the way I do get funky tmux window layouts, but that's after switching to tmux 2.5.

I'm wondering it could be something to do with tmux configurations and v2.5 (which would be ideal) because I haven't reproduced these things on my end. Though I set my options for main-pane-height with using main-vertical.

I'm guessing it would be main-pane-width if using main-horizontal?

[oblitum]

@tony I got the issue both main-horizontal and main-vertical, so this doesn't matter. Yes I can state for sure, as I'm now frozen on 1.3.2 on pacman, this version is fine.

[tony]

I am perplexed. Tomorrow morning I'm going to start giving this a look

[tony]

I kept mentioning 2.5 last night, I meant 2.6.

Based on the discussion, this seems to be about tmuxp version.

I'm of the belief for some reason that it's more to do with 2.6's changes, namely how detached windows are treated (tmux/tmux#1106).

tmuxp creates workspaces detached. tmux 2.6 sets the dimensions of these workspaces to 80x24. This can cause issues when running stuff like select-layout in workspace builder, which is similar to the symptoms being described in this thread.

[tony]

Debugging, writing down some thoughts:

Here's the issue, even if giving -x and -y to new-session (which we are already doing), the selectl commands don't stick until the real client is attached.

This poses a tricky issue. There are ways libtmux can pass a ; selectl after the session is attached (using semi-colon to do a multi-command). But that only will fix the first window.

The same applies for using hooks in various ways, for instance:

# from powerline (required)
run-shell "tmux set-environment -g TMUX_VERSION_MAJOR $(tmux -V | cut -d' ' -f2 | cut -d'.' -f1 | sed 's/[^0-9]*//g')"
run-shell "tmux set-environment -g TMUX_VERSION_MINOR $(tmux -V | cut -d' ' -f2 | cut -d'.' -f2 | sed 's/[^0-9]*//g')"

# on tmux 2.6 and greater, it's not possible to select-layout until client is attached
if-shell "test '\( #{$TMUX_VERSION_MAJOR} -eq 2 -a #{$TMUX_VERSION_MINOR} -ge 6\)'" 'set-hook -g client-attached "selectl"'
if-shell "test '\( #{$TMUX_VERSION_MAJOR} -eq 2 -a #{$TMUX_VERSION_MINOR} -ge 6\)'" 'set-hook -g after-select-window "selectl"'

This gets the layout running after attaching. And also the first windows you select after. But here's the issue, it always runs selectl, every time you move windows.

# -gu disables the hook after first run
if-shell "test '\( #{$TMUX_VERSION_MAJOR} -eq 2 -a #{$TMUX_VERSION_MINOR} -ge 6\)'" 'set-hook -g after-select-window "selectl; set-hook -gu after-select-window"'

This only will fix the first window you traverse to.

An idea to fix this universally. tmuxp can have a command like tmuxp windows foreach <cmd> which runs a commands for all windows in a session. If we make that run with a semicolon via run-shell, that may get us the prior behavior we had.

A second idea would be to use a pure shell command that unsets with set-hook client-attached "<cmd> set-hook -gu client-attached. This would give the same behavior with no perceptible difference to the user, and still allow detached building.

Another option would be to not build clients in a detached state.