I did some digging and found the answer for myself. Well, the way I have found to accomplish my gaol is not elegant, but it will work to get the job done.
First, you need to have the "set-titles" option turned on in your .tmux.conf file. As well as the appropriate title string:
set -g set-titles on
set -g set-titles-string '#T'
However, if you implement this, you will immediately notice that it doesn't work. The problem is that this only sends the title string up stream if it starts in an xterm variant (tmux/screen TERM variable is "screen*"). So, when starting a nested tmux session, you must fool the terminal by resetting the variable. The following example will keep the TERM suffix (e.g. "-256color").
TEMP_TERM=$TERM
TEMP_TERM_SUFFIX=${TERM#$(echo $TERM | cut -f 1 -d'-')}
TERM="xterm${TEMP_TERM_SUFFIX}"
I am not sure if it matters, but I think it is smart to reset TERM back after closing tmux (so save it into a temp variable). Using this, a simple shell script can be made to open a nested tmux session that sends the #T title variable upstream to it's parent sessions.
This all works, but is somewhat of a pain considering that work must be done to ensure infinite nesting loops aren't created in the event that we automatically start our shell up in tmux. If anyone has a better solution I would love to here it as well!
This is what is happening:
tmux new 'tmux source-file ~/.tmux/dev'
The new
commands creates a new session with a single window that has a single pane. The command tmux source-file ~/.tmux/dev
runs in this new pane.
- So, you have a new session
N
(where N is some number), with
- a single window
N:0
(or whatever you have base-index
set to), with
- a single pane
N:0.0
(or whatever you have base-pane-index
set to),
- running the command
tmux source-file ~/.tmux/dev
.
The source-file
command is processed.
- The extra panes are added.
- Pane 0 is (re)selected.
- The
send-keys
command then “types” vim .
+ Enter at pane 0.
This input is ignored because this pane is just running the tmux client that sent the source-file
command.
- The tmux client exits, thus closing pane 0.
So the unexpected bit is that pane 0 (i.e. N:0.0
) is running (only) the source-file
command which ignores your “typed” command. This pane never runs an interactive shell that could interpret the “typed” command.
There are at least a couple of ways you can fix this:
Start ~/.tmux/dev
with new-window
so that pane 0 is running your “default command” (i.e. probably an interactive shell).
This method has the benefit of not assuming that your current pane is running an interactive shell, and also not assuming that the current pane is 0
(i.e. what happens if you run your original series of commands against a pane that is part of an already split window?). It means you can safely bind source-file ~/.tmux/dev
to a key that you can run in any context (since it creates a new window for all of its panes). From the shell you can run either tmux source-file ~/.tmux/dev
(to create a new window in the current session), or your original tmux new 'tmux source-file ~/.tmux/dev'
to create a new session.
A minor drawback to this method is that when you run tmux new 'tmux source-file ~/.tmux/dev'
, the initial window will still run the client that sends source-file
and exit fairly quickly. This means that your “main window” (the one with the splits) will be one higher than your base-index
and a future new window will be placed before the “main window”. You could fix this by using something like this:
tmux new 'tmux move-window -t 99 \; source-file ~/.tmux/dev'
It moves the (ephemeral) initial window to a high index so that the new-window
in ~/.tmux/dev
will end up at base-index
.
Use (e.g.) tmux new 'tmux source-file ~/.tmux/dev ; zsh -l'
so that the pane ends up running an interactive shell after the source-file
command finishes.
The ugly bit about this is that you end up “hard coding” your preferred shell into this command. Also, the send-keys
input (vim .
+ Enter) is technically sent before the shell starts; this is probably okay, but may not always be completely reliable.
You could avoid “hard coding” your shell by querying tmux for the default-command
(or if that is not set, default-shell
(or if that is not set, using SHELL)), but that may be more work than you really want to do.
Best Answer
There must be a race condition in tmux on cygwin, because changing
escape-time
from 0 to 1 fixes it for me most of the time.For values above 50ms this issue never appears again.