start_directory doesn't work when set on session, window and pane

[rightaway]

When start_directory is set on all of session, window, and pane, it doesn't work as expected.

It should concatenate directories for session + window + pane, inheriting from the parent level if nothing is specified.

So a pane that has no start_directory on window should get the directory from session + pane. And a pane that has nothing set for itself should get the directory from session + window.

[rightaway]

@tony Thanks for taking care of #326. Do you think you could take a look at this issue too? It's the only thing holding me back from getting rid of tmuxinator once and for all and finally switching to tmuxp! :)

[tony]

@rightaway I pinned this

Is there a PR for it? Do you have any more info that'd be helpful getting this added in tmuxp?

[rightaway]

I don't have a PR myself but I'll provide any additional info that you need.

start_directory: /top/level
windows:
  - panes:
      - command_one
  - start_directory: two
    panes:
      - command_two
      - start_directory: three/four
        shell_command: command_three
      - start_directory: ~/my/four
        shell_command: command_four
  - start_directory: ~/my/five
    panes:
      - start_directory: under_five
        shell_command: command_five

So command_one should be in /top/level, command_two should be in /top/level/two, and command_three should be in /top/level/two/three/four. This is because these are relative paths so they get appended.

But because command_four has an absolute path, it should be in ~/my/four. Same with command_five, which should be in ~/my/five/under_five.

[rightaway]

@tony is there a roadmap we can see with what features are most priority for the next versions?

[tony]

@rightaway we don't have a system for that yet. we may use discussions or the beta version of projects.

i will look into setting up a system for that

My #1 priority of the now is lowering the barrier to contributing (cleaning up spaghetti code, test infrastructure) and writing developer docs so these are easier for others to contribute.

[tony]

@rightaway Regarding this particular issue

We do have start_directory support, it's tested and functioning. I concede it probably needs to get a fresh look at.

As of 1.9.4

https://github.com/tmux-python/tmuxp/blob/v1.9.4/tmuxp/workspacebuilder.py#L143-L147

https://github.com/tmux-python/tmuxp/blob/v1.9.4/tmuxp/workspacebuilder.py#L258-L274

https://github.com/tmux-python/tmuxp/blob/v1.9.4/tmuxp/workspacebuilder.py#L317-L333

https://github.com/tmux-python/tmuxp/blob/v1.9.4/tmuxp/workspacebuilder.py#L419-L431

Tests

https://github.com/tmux-python/tmuxp/blob/v1.9.4/tests/test_workspacebuilder.py#L425-L503

Two test fixtures:

• https://github.com/tmux-python/tmuxp/blob/v1.9.4/tests/fixtures/workspacebuilder/start_directory.yaml
• https://github.com/tmux-python/tmuxp/blob/v1.9.4/tests/fixtures/workspacebuilder/start_directory_relative.yaml

@rightaway I wonder if either of the above would help you find a workaround?

[rightaway]

Workaround would be to use full path in each start_directory. Concatenating is a nice to have.

[tony]

Workaround would be to use full path in each start_directory. Concatenating is a nice to have.

@rightaway I think your comment at #422 (comment) makes sense to me.

In the mean time I welcome PRs. If I or someone else gets to it, we can chime in here

P.S. I recommend pathlib for this. I think it'd potentially make the code cleaner. I'm moving our .join() to use that.

[tony]

I don't have a PR myself but I'll provide any additional info that you need.

start_directory: /top/level
windows:
  - panes:
      - command_one
  - start_directory: two
    panes:
      - command_two
      - start_directory: three/four
        shell_command: command_three
      - start_directory: ~/my/four
        shell_command: command_four
  - start_directory: ~/my/five
    panes:
      - start_directory: under_five
        shell_command: command_five

So command_one should be in /top/level, command_two should be in /top/level/two, and command_three should be in /top/level/two/three/four. This is because these are relative paths so they get appended.

But because command_four has an absolute path, it should be in ~/my/four. Same with command_five, which should be in ~/my/five/under_five.

One idea to explain it more clearly, instead of writing this:

So command_one should be in /top/level, command_two should be in /top/level/two, and command_three should be in /top/level/two/three/four. This is because these are relative paths so they get appended.

But because command_four has an absolute path, it should be in ~/my/four. Same with command_five, which should be in ~/my/five/under_five.

Write a second configuration YAML to show what this would look like specifically? So they can be compared?

I think the gold standard for this issue would be to write a test that at least asserts the behavior (and makes sure its fleshed out and doesn't impact existing stuff that works already):

https://github.com/tmux-python/tmuxp/blob/v1.11.0b0/tests/test_workspacebuilder.py#L433-L516