Current coverage is 83.91% (diff: 100%)

Merging #197 into master will increase coverage by 0.08%

@@             master       #197   diff @@
==========================================
  Files             5          5          
  Lines           742        746     +4   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits            622        626     +4   
  Misses          120        120          
  Partials          0          0          

Powered by Codecov. Last update df60657...613622d

This is breaking tests on tmux 1.8.

Maybe it can be a conditional support on the tmux version?

Done!
But there seems to be a problem with libtmux's is_version function when tmux's version is 1.9a (probably a parsing problem)

Rebased against df60657

@minijackson can you make tests for this?

Sure thing

Unfortunately, I can't find a way to get the working directory of a session (even with tmux commands). I could inspect the process to see it's cwd, but that doesn't seem to be the right solution to me…

The session's environment doesn't have the right PWD, so I'm guessing that even inspecting the process is a no-go

Sorry for the late response, I am having issues keeping up with the project. I'm seeking maintainers @ #290. If you (or someone you know) may be interested in helping maintain libtmux or tmuxp, feel free to contact me by email or in the #290 issue.

In the mean time, if you're still interested in this PR, can you rebase it via git pull --rebase origin master?

@minijackson Can you rebase this?

I just merged #623 which moves us to a poetry packaging setup and will runs the PR through GitHub actions.

Also, air traffic control, is this the same as #403?

@tony Yes this is an implementation of the same feature as #403, with the check that Tmux is not 1.8. I'll rebase the PR in a quick moment.

Done!

@minijackson Thank you! Is it possible you could check out the linting issue?

@anddam I just had an issue with you being let out of a PR at #441. In this case it seems @minijackson had this before you, but do you have any comments on this approach vs your own?

Codecov Report

Merging #197 into master will decrease coverage by 0.13%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master     #197      +/-   ##
==========================================
- Coverage   77.08%   76.95%   -0.14%     
==========================================
  Files           6        6              
  Lines         829      833       +4     
  Branches      238      239       +1     
==========================================
+ Hits          639      641       +2     
- Misses        131      132       +1     
- Partials       59       60       +1     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bdb2154...52fcceb. Read the comment docs.

Lint should pass now ^^

Oh, I cannot find the is_version function in libtmux anymore...

There we go! It simply was renamed to has_version

@minijackson That leads me to a more questions, since if I publish, this goes to a lot of users that already have a bit of using tmuxp without this

If I could - I'd just have had this have been the default behavior. My concern is atm people are relying on this and triggering automated stuff. I'm wondering if we should add this - but feature flag it somehow so users aren't caught with a new behavior off guard

Would this change behavior / disrupt any users using the current behavior as it is on master as of now? (e.g. what if they're relying on start_directory's behavior not setting stuff? e.g. they have a script executing somehow)

Is this something we should issue a deprecation warning behavior ? Have toggleable via an option? Phase it in via an env variable?

Could you write something to CHANGES explaining the behavior? Explain the behavior in the documentation?

Also I may be overthinking it by the way - let me know what you think 😊

I think you're right that this changes could break some setup for end user: if a launched script creates a new window or pane dynamically for example. This may be a quite specific usecase, but not impossible to imagine. Breaking this usecase could be avoided by adding a new option (like session_directory) instead of using the start_directory.

I don't think this is optimal, since that means the behavior of the session's start_directory and the window's start_directory are incoherent: new panes are created under the window's start_directory, but new windows would not be created under the session's start_directory. But this is the current behaviour and users are used to it.

I'm afraid the choice isn't clear cut, and I don't think it is mine to make, but either way I'm happy to use a different option name, and update the doc if you want.

@minijackson I propose you document this in CHANGES and docs, and we merge this

I think I will then release this in 1.6.0, rather than a bug/patch-level release. To be super safe. Rationale:

• If someone was doing a serious command it'd be done manually
• If someone was doing something very niche, it'd be through tmux itself
• This behavioral change comparable to tmux(1)'s version bumps
• If someone was doing commands that'd break stuff, they shouldn't update feature releases
• The effects of this are really minor, they only effect newly created windows in a session, and they're matching the behavior normal tmux users would expect

@tony That's fine with me! I'll see if I can document that tomorrow.

@minijackson Sounds good!

@tony I'v updated the CHANGES file, but I'm not sure if or where I should update the documentation

@anddam […] do you have any comments on this approach vs your own?

He actually managed the 1.8 case I was asking about in my PR.

@minijackson I am unsure of what the original problem was here, but it seems like this may be solving the case of new windows/panes (from tmux vs tmuxp) being created in the original directory where tmuxp was run. If this is the case, a bug hotfix was just released last weekend that fixes this problem (v1.5.8+).

Yes, looking at the diff of #639, it seems that this PR is now a duplicate. Thank you for telling me!