Fixed auto-renaming of windows (#57)

[mayanksuman]

The automatic-renaming option of each window is saved in session files and restored accordingly.

[noscript]

This PR somehow resets all windows names to default ("zsh" in my case) when saving a session.

[mayanksuman]

Interestingly, in my case the windows names are not being set to default.

@noscript Can you please share more information like OS, tmux version, autorename setting as in tmux.conf and ways to reproduce the problem you are facing?

The older commit did have some problem. Please use the latest commit (fd86b59; FIX: consider the global automatic-rename option) for testing.

[zeorin]

Please could we look at getting this merged? Seems like the fix has been available for 6 months…

[smu160]

Is there a plan to have this merged? For the time being, I found a workaround here.

Thank you!

[bruno-]

This feature is more complex than it looks like. That's partly due to some existing code in the plugin: for example we restore window names even when automatic-rename is on. But also the behavior of automatic-rename is complex in itself.

Let me know if someone is willing to take a deep, hard look at this feature and do it right. I'm willing to provide guidance all the way through.

We'll need to:

1. Change some of the existing code
2. Observe carefully how tmux behaves in regards to automatic-rename option.
3. Finally, write some code (similar to this PR) so that automatic-rename is saved and restored properly

[smu160]

@bruno- Thank you for addressing this issue. I'd be glad to attempt to take a look at it.

[bruno-]

@smu160 great, thanks.

Here's some more input on this feature:

• I think we'll want to move window_name value from resurrect's pane to window data https://github.com/tmux-plugins/tmux-resurrect/blob/716b958145e2709e9fd3639ff24e1d1e4f26ff77/scripts/save.sh#L36 I think window_name was originally added to pane data so that it's easy to create a pane and set the window name at the same place https://github.com/tmux-plugins/tmux-resurrect/blob/716b958145e2709e9fd3639ff24e1d1e4f26ff77/scripts/restore.sh#L175 Since we're doing window naming right now, I think this will need to change.

• automatic-rename can be set in two places:

  • global: tmux show -g automatic-rename
  • window: tmux show -w automatic-rename Window-level automatic-rename may be set (on or off), or it may be completely unset and the command will not return any value. You can unset window value with tmux set -u -w automatic-rename.

• I think we want to save only window-level value. This can be an empty value if tmux show -w automatic-rename is empty. If empty, we need to use some other placeholder value. I've used : char for this https://github.com/tmux-plugins/tmux-resurrect/blob/716b958145e2709e9fd3639ff24e1d1e4f26ff77/scripts/save.sh#L40

• Global value can be ignored for save and restore purposes as it's set from user's tmux.conf

Let me know if you have enough to get going? You can open a new issue or open an uncompleted PR when you have something. Note we'll probably do a couple iterations on this feature until it's right. We don't want hasty solutions for this one.

[Farzat07]

Actually I believe this implementation is quite complicated for the simple task it tries to achieve.

You can check my implementation at #399.

[bruno-]

Actually I believe this implementation is quite complicated for the simple task it tries to achieve

Unfortunately, tmux's behavior with automatic-rename is more complex than with other options. We could "get by" with simple implementations, but I don't wanna do that anymore. We also need to fix some existing code.

@Farzat07 let me know if you're up to implementing a proper fix for this.

[Farzat07]

@bruno- I said the implementation was too complicated not because it is trying to take into account the various possible scenarios, but because it is using numerous numbers of code with if statements just to exactly replicate the exact same functionality provided by the #{?automatic-rename,on,off} format option.

Complicated code can be better when it is able to handle specific scenarios more properly as needed. However, when all the complicated code is doing is replicate the functionality already provided by tmux (as in this case), then that no longer holds.

Even when complicated code is able to handle more specific scenarios, one needs to evaluate whether it is worth it. Complicated code opens more surface for errors and makes it more difficult to debug, and is often (but not always) less efficient. One needs to study whether these specific scenarios are valid in the first place, and whether enough users will need that scenario to justify its implementation.

Anyway, I don't really mind taking the more complicated approach to achieve the perfect case of keeping the auto-rename option unset where appropriate. Actually that was my plan at the start, but then I chose to just use the built-in functionality. What I am saying is that one shouldn't criticise an implementation for being simple - simplicity is always an advantage. The problem my PR is not the simplicity, but the existence of a case which is handled less perfectly than possible (which applies to this PR as well).