Hi Without many big changes to tmux, you can't make a tmux client talk to a tmux server over a network (you can't pass file descriptors remotely). Not to mention the huge security issues.
I think the way to do this is to write a new tmux client that uses control mode. Control mode was designed to let a local client (iterm2) automatically ssh in and talk to a remote tmux server. AFAIK iterm2 only supports connecting to one server but there is no reason that a client couldn't use control mode to attach to multiple servers. I am open to making changes to make this possible even if it doesn't work today. It'll be a lot of work though, because you are writing a new terminal and a new UI for tmux. On Wed, Oct 29, 2014 at 12:09:26AM -0700, Merijn Verstraaten wrote: > Ola, > > One of my age long pet peeves has been the poor integration between my > local tmux environment and tmux sessions running on servers, such as > having no shared clipboard, the annoyance of needing to different > prefixes for nested sessions, etc. > > Recently I've been thinking a bit about how to fix this in a > satisfactory way. An obvious solution (to my na??ve eyes) seems to be > to allow a tmux-client to connect to multiple servers. Allowing the > user to list the sessions of *all* connected clients and select them. > > From a user-perspective I would want "tmux choose-tree" to list all > sessions from all servers (labeled with the relevant server) and all > their windows and transparently switch between them. I'd want to have > access to the same copy/paste buffers. > > Potential problems I see: - Windows can be shared between sessions, > but it makes no sense to share windows between sessions on different > machines. - Are copy/paste buffers currently per client, per session > or per server? If the latter two, the client needs to somehow unify > these multiple sets of buffers > > This email is mostly meant to ask for opinions/sanity check before I > sink any non-trivial amount of time into exploring the > code/hacking. Is this a stupid idea? Is the idea ok, but does it not > fit the current tmux design without a lot of work? Any problems I > missed? Suggestions for resolving the above mentioned problems? Any > odds of working code for this getting merged back into tmux? > > Cheers, > Merijn > ------------------------------------------------------------------------------ > _______________________________________________ > tmux-users mailing list > tmux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tmux-users ------------------------------------------------------------------------------ _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
