Not to worry, the plan won't break your current workflow if that is what you prefer.

So far what we have discussed is an API between iTerm2 and tmux that would allow tmux's state to be reflected in iTerm2's. My goal in proposing this idea was to make the environment seamless. There are cases where that may not be desirable (such as when you have 300 tmux windows) and the onus will be on iTerm2 to accommodate the user and do something reasonable.

This new mode, when implemented, would be enabled by a new command or command-line option to tmux. If you prefer not to use it, you can not enable it.

On Thu, Nov 25, 2010 at 7:11 AM, kevin beckford <chiggsy@lazyweb.ca> wrote:
I'm a bit lost here, tmux via iterm2 already works exactly as one
would expect, in fact I was planning on testing iterm +tmux -> ssh ->
screen in about 33 hours or so.

It seems to me, a user, that SSH already makes things transparent.  It
actually all works fine, I'm exactly as happy as the day I discovered
the "Mensch.ttf" font with the fat brackets.

What about security issues?  Would they be affected by these proposed changes?