Status is not changed when switching to other window or pane

[justfortherec]

Apparently the status bar is only updated on issuing cd or git commands. At least I experience that the status does not update when I switch to a different window or pane.

An example: I have one window with two panes next to each other.

+-----------+-----------+
| ~/A$      | ~/B$      |
|           |           |
+-----------+-----------+

In the left pane, I'm currently in repository A and the tmux status line also correctly displays repository name and branch. However if I switch to the right pane, the status bar still displays A | branch: master, although the working directory is B, which is a different repository.

Similar behaviour can be seen when switching between a pane within a repo and one outside the repo. Information about git is only updated after switching directory or running some git command.

For me this kind of defeats the purpose of this nice script. Is it possible to update the displayed information when switching between tmux' panes and/or windows?

Thanks

[drmad]

Hi, thanks for your feedback! :smile_cat:

The script is executed everytime the bash prompt is shown. That won't happen when you switch panes or windows. A simple <ENTER> in the active pane/window will trigger the script.

I don't know if tmux have some sort of hooks for executing something on pane changing. I'll look into it.

[justfortherec]

Thanks for that piece of info, it already helps.

tmux seems to have hooks as an upcoming feature. At least they are mentioned in the todo file and there exists a branch called hooks-new.

For now -- however -- there doesn't seem to be a way to solve this issue.

[rlue]

What is the status on this? It appears these hooks were added to tmux 2.6 as of August this year. (It's not in the man pages, but I've tested it myself, and it definitely works.)

I'd submit a PR myself, but I'm honestly not 100% sure what the best way to do it is. I thought you could simply

set-hook after-select-pane "run-shell -b update_tmux"

but that returns 127, which I think happens because the alias is unrecognized (i.e., because tmux tries to execute the shell command outside the context of the given pane).

Love this script, by the way.

---

For the record, it appears that calling a function from the tmux command line is tricksy indeed:

As far as I know, you can not export shell functions to a tmux instance. At least in the 1.9 version of the tmux man page there is no reference to it.

I do not think this is possible at all since the context of the script where you are creating the tmux session is entirely different from the context within the tmux session. Thus it is not even able to have knowledge of these functions. Also, tmux might even use a different shell than the one you are using.

However, to provide some alternatives, what you can do is one of:

1. Write another script, put your internal function in it and use that instead.
2. Write a library script containing all your functions but nothing else, source that library script in application scripts so it's [sic] functions become available there and use these application scripts instead.

The second alternative also gives you more code hygiene and better reusability.

Since update_tmux depends so heavily on the setting of various shell variables defined by other functions, I imagine Option 2 is the way to go here.

[drmad]

Hi @rlue. This definitely needs some work to set it up correctly. I have a few ideas, but I'll try them later.

I'm reopening this issue. Thanks for your input :+1:

[shubidubapp]

is this still a thing? are you working on it?

[drmad]

~3.5 years later, and this is still a thing :grin: I've tried a few things about it using the tmux hooks, none worked as expected :stuck_out_tongue_closed_eyes:

The problem is that bash is very... weird :stuck_out_tongue: I've tried signals and file descriptor to try to send a message to it so it would rerun the update_tmux() function, and nothing...

It would be easy if we use an external script/program, but the idea is that this script should be standalone, and works only with bash/gnu and nothing else.

I'll continue to investigate about this issue. I'll keep you all posted.