> Entirely separate process that could fork a "tmux -C attach", it
> wouldn't even need to be C.
Ah, now I understand what you meant. That's quite different from what
I had in mind.
The desire to log sessions can't be that strange. Different terminal
emulators, like putty, iTerm, and KDE's kons
Entirely separate process that could fork a "tmux -C attach", it
wouldn't even need to be C.
Whether that would suit your requirements or not I don't know.
On Wed, Jul 31, 2013 at 05:38:55PM -0500, J Raynor wrote:
> > You could possibly record it externally by starting a control client
> > for e
> You could possibly record it externally by starting a control client
> for each session and listening for %output.
By "externally" do you mean a separate process? Or just a separate
bufferevent processor (external to the pane), so that each pane isn't
doing its own file writing?
--
For panes they do not, left and right are the physical pane position but next
and previous are numerical order as shown by C-b q. For many layouts these are
not the same.
For windows next and right are the same but this is intended.
Original message
From: Cory Sharp
Date: 31
That's unfortunate. In general I do not see the benefit of the wrapping
behavior. If select-pane wraps, then In the common case of two panes side
by side, then the commands "next pane", "previous pane", "select pane
right", and "select pane left" all degenerate to precisely the same toggle
behavior
Thanks for your diff but I don't want to add it, sorry. This is not
something where we need a choice of behaviours - one is enough, and
wrapping is it.
On Wed, Jul 31, 2013 at 09:21:00AM -0700, Cory Sharp wrote:
>I sometimes tmux over an intermittently high latency connection. *In that
>s
I sometimes tmux over an intermittently high latency connection. In that
scenario , when on a right-most pane, for instance, it is very useful if
select-pane -R just stays on the right-most pane instead of wrapping around
to the left-most pane.
As a proof of concept, I have attached a patch that
