"no previous window" status line output when loading a session

[oblitum]

Following from #316 that got automatically closed, the problems still persist. The tmux message "no previous window" always shows up when switching between tmuxp created sessions. This started when #312 got merged in an attempt to fix #309, but whose sole solution was actually provided for libtmux here and merged here, the rest that was added as an attempted solution is solely causing misbehavior when compared to tmuxp 1.3.2/libtmux 0.7.4.

System:

• tmux 2.6
• tmuxp 1.4.0
• libtmux 0.8
• ArchLinux

To reproduce it's solely necessary, from inside a tmux session, to load another one through tmuxp (tmuxp load -y ./foo.yaml). When you switch between sessions, the error message shows up on the newly created session.

For me on ArchLinux, tmuxp 1.3.2/libtmux 0.7.4 is still the last release that's usable.

[cowboy]

I also see this, when switching to a session that has only one window. Once I've created a second window in the target session (it can be subsequently deleted) I no longer see the "no previous window" error message.

I'm using tmuxp 1.4.0 and tmux 2.6 in MacOS 10.13.3.

[oblitum]

@cowboy have you tried to use the pinned versions I mention to avoid the issue?

[tony]

Maybe it would make sense to only create the hook based on a condition of current windows/panes open? Or to make the conditions of the hook more specific?

[tony]

As an idea, it'd be helpful to create a test case / PR that recreates this error.

[oblitum]

My test case is just:

To reproduce it's solely necessary, from inside a tmux session, to load another one through tmuxp (tmuxp load -y ./foo.yaml). When you switch between sessions, the error message shows up on the newly created session.

Is anything left to describe how to reproduce it? Also, same thing in the previously auto closed issue:

The session must be created by tmuxp, I'm using this one:

session_name: foo
windows:
- layout: main-vertical
  options:
    main-pane-width: 160
  panes:
  - blank
  - blank
  - blank

I start it from inside a tmux session (tmuxp load -y ./foo.yaml, -y or -d doesn't matter). I've noticed that I do get this message "no previous window", right when I start and enter the session with tmuxp load -y ./foo.yaml, prior to applying zoom, etc.

[tony]

Yeah I'm reproducing it. Thanks for that

The other issue is I haven't been building regression test suites for stuff like this. Without that it turns into a whack-a-mole where fixing one bug, unveils another. We already have a pretty solid test suite actually.

It's probably not necessary in this situation, but if hypothetically, an issue was recreated in the test suite it helps me to debug it. I know it takes time. I'm stretched a bit thin and need help with the project. It helps with the regression part of it.

The most important thing is this project needs right now is helpers that can pitch in time. I'm happy documenting it, improving the test suites a bit more, etc.

[oblitum]

All I can say is that it was added on the #312 convoy. I still don't know whether #312 brought any value. As I explain in this issue's description, #309 was fixed by this and this, so what does #312 do? I don't know, maybe just try reverting it would be enough.

[tony]

@oblitum Yeah

#312 needs a regression suite built around it.

It's necessary because 2.6 introduced an issue where the dimensions of unattached screens can't calculate layout info/switch layouts. get what I mean? That's why the hook was added.

The the thing is, the hook may need to be tailored to fit more specific instances so issues like this don't bubble up. Whether it's:

• the conditions under which the hook itself is created,
• the hook's specificity to a target/global
• when it's added in the workspace creation process
• or adding more conditions inside of the callback itself

[oblitum]

I don't know what you mean. I'm still frozen on tmuxp 1.3.2/libtmux 0.7.4 because it works, and I'm on tmux 2.6.

[tony]

I created at TODO issue at #375 which should help servicing issues around #312. It's create a test fixture checking out that tmux hook/seeing what's up.

[tony]

I don't know what you mean. I'm still frozen on tmuxp 1.3.2/libtmux 0.7.4 because it works, and I'm on tmux 2.6.

That post was purely development related: Tests need to be written to recreate the bugs, and to make sure that bugs that take time to replicate are automatically checked for to make sure they don't come up again. https://en.wikipedia.org/wiki/Regression_testing

Are you having this issue on the latest tmuxp/libtmux? I'm assuming yes, because I created it.

I reopened #316 to look at recreating/getting more info on that

[oblitum]

Are you having this issue on the latest tmuxp/libtmux?

As I reported:

System:

• tmux 2.6
• tmuxp 1.4.0
• libtmux 0.8
• ArchLinux

I just tried 1.4.0 once, hopping this got fixed, and then went back to 1.3.2.

I'm assuming yes, because I created it.

???

[oblitum]

That post was purely development related

I meant that I don't know what you mean with "It's necessary because 2.6 introduced an issue where the dimensions of unattached screens can't calculate layout info/switch layouts. get what I mean? That's why the hook was added", which is not purely development related, it tells about some feature that looks like it should be crucial for me as a user on tmux 2.6, but which in truth I have no idea about, hence I said I'm on tmuxp 1.3.2 without issues, 1.3.2 doesn't try to cover this hook thing or whatever was added in #312 which is causing the issues.

[tony]

Got it.

Added explanation: tmux 2.6 requires that tmuxp's workspace builder, in some fashion, adds a hook to handle layout stuff. What this means is layout proportional stuff is deferred until the user attaches the session itself. That's what #312 did.

It's possible we may even need similar fixes for focus stuff with a hook, (e.g. #326/#370), but I haven't checked yet.

[cowboy]

@cowboy have you tried to use the pinned versions I mention to avoid the issue?

@oblitum I don't know what you mean by "pinned versions." Can you elaborate? Thanks!

[oblitum]

@cowboy I state in the issue description that tmuxp 1.3.2/libtmux 0.7.4 is the last release that's usable.

[rjkat]

+1 can confirm - am having this issue and reverting to 1.3.2 fixes it.

[tony]

@rjkat @oblitum If you would like to carve out a minimal PR that fixes the issue, that would be helpful.

That way the specific line or lines of code causing the issue would be established in a diff. The reason why is the thread seems to speak of whether the changes in #309/#312 were justified or not.

No need to address the older issues at this point. All that's needed is a minimal PR master that'd fix the issue, then we can discuss what to do next / work off that.

[larsks]

I just started working with tmuxp (tmuxp 1.5.1, tmux 2.9a), and I'm seeing the same issue: whenever I start load a session with tmuxp load ..., I see the "no previous window" error message. This reproduces with a tmuxp session as simple as:

---
session_name: example
windows:
  - start_directory: ~/
    layout: tiled
    panes:
      - null

[pearagit]

If anyone is looking for a low effort fix, you can add a second window to your projects tmuxp.yaml file with one pane that just runs exit. Example file:

session_name: example
windows:
- window_name: terminal
  panes:
  - pane
- window_name: exit
  panes:
  - exit

[tony]

Status:

• [ ] re-production of the bug in CI / pytest
• [ ] assure tmux 2.6+ compatibility works with layouts (either by fixing or adapting #312's changes or finding an alternative way to do it)

Can someone create a PR that recreates this issue in pytest (so its reproduced in our CI?)

Also - is there any proposed fix to #364 / 1.4.0's change that gets us the same effect #312 has? (context here)

cc: @kintsugi @larsks @rjkat @oblitum

Are there any common denominator to systems where this does and doesn't happen?

[oblitum]

Hi @tony, at here you stated to have reproduced it, at the time I think it was on macOS or FreeBSD. I think from that and other comments here it can be widely stated it's not platform specific (I use Arch Linux), and that people kept reproducing it along the years until very recently.

[tony]

@oblitum I'm referring to reproducing it on CI (e.g. having it created / asserted via pytest) - we don't have that, right?

Thanks for pointing me to https://github.com/tmux-python/tmuxp/issues/364#issuecomment-377795455 as that does jog my memory a bit

[oblitum]

we don't have that, right?

afaik, no.

[tony]

@oblitum My aim / intention is to get this fixed before tmuxp's python 2.7 is dropped

[bszonye]

I'm encountering this while trying out tmuxp for the first time on WSL Ubuntu 22.10, using the tmuxp 1.11.0 and libtmux 0.10.1 packages supplied by Ubuntu. I'm using this simple three-pane configuration:

session_name: 'windows'
windows:
- window_name: main
  focus: 'true'
  layout: a4cc,169x58,0,0{90x58,0,0,0,78x58,91,0[78x29,91,0,1,78x28,91,30,2]}
  panes:
  - focus: 'true'
  - pane
  - pane
- window_name: workaround
  panes:
  - exit

It starts up immediately with the second workaround window. Without that, there's a long (2-3 second) delay with the "no previous window" error message.

[tony]

@bszonye Welcome!

Do you have pip? Is there any chance you can try updating to the latest tmuxp version and see if it happens also?

[bszonye]

Sure thing! A fresh pip3 install tmuxp gets me: tmuxp 1.18.2, libtmux 0.15.10

I can still reproduce with this test config (slightly simplified from above):

session_name: 'test'
windows:
- focus: 'true'
  layout: a4cc,169x58,0,0{90x58,0,0,0,78x58,91,0[78x29,91,0,1,78x28,91,30,2]}
  panes:
  - focus: 'true'
  - pane
  - pane

It's not a dealbreaker, as I can use the workaround, but I figured you'd want to know that it was easily reproducible with the latest Ubuntu on WSL. I tested both in Windows Terminal and Conhost (the two built-in Windows terminals).

[bszonye]

I also tested without the layout and focus options for a more minimal test case, same result.

[tony]

@bszonye Thank you!

tmux version

Can you see what your tmux(1) version is?

tmux -V

This one may be harder to do: but if you have a way to get a more recent tmux version, e.g. 3.1 or 3.2, I'm wondering if that helps or not.

tmuxp debug info

This may provide some clues:

tmuxp debug-info

Traceback

Also - if you do get the error, is there a traceback? If there is, it would likely mention a file like this: workspacebuilder.py (in newer versions of tmuxp that file is workspace/builder.py)