Tmux Control Mode (squashed)

[manno]

This is the tmux code from 2016 applied on top of the current master branch.

It's not functional yet.

(for #79)

[mattrose]

Wow, thanks for this. I'll pull this in and take a look at it as soon as I can, and hopefully I can help you work through the remaining issues.

[mattrose]

Seems to work so far, and the test failing is a simple fix. What specifically is not working?

[manno]

Seems to work so far, and the test failing is a simple fix. What specifically is not working?

So back then, the decision was made to develop tmux support mostly independent of the main code path.

Clients like iterm2 detect tmux control sequences and open a new window (echo -e '\x1bP1000p%begin 1612615231 294 0\n%end 1612615231 294 0\n'), but terminator would wrap all of that.
I wish it was different, as this means dealing with SSH and tmux binaries.

So terminator -t is equivalent to running tmux -CC in iterm2 and terminator -t --remote host is like ssh -t host tmux -CC or just typing tmux -CC in an ssh connection. Terminator would not allow the user to specify arguments (like session name and attach).

It also means, the code in this PR won't execute unless terminator is started with ./terminator -t. And that code path currently runs in to an error:

Traceback (most recent call last):
  File "/home/mm/co/terminator/terminatorlib/terminal.py", line 1326, in do_deferred_on_vte_size_allocate
    self.on_vte_size_allocate(widget, allocation)
  File "/home/mm/co/terminator/terminatorlib/terminal.py", line 1329, in on_vte_size_allocate
    column_count = self.vte.get_column_count()
AttributeError: 'NoneType' object has no attribute 'get_column_count'

I'm not sure how to fix that, but if it's complicated to fix, I'd suggest to just detect the escape sequences and react to them and throw all the popen ssh/tmux code away.

[mattrose]

Just checking in to say I'm pretty busy starting a new job right now, but I'll take a look as soon as I can. I haven't forgotten about this.

[iamjackg]

I actually think the "bypass" approach makes a lot of sense in terms of usability since it would otherwise require an inter-window communication method and add more UX concerns. I'm hoping to find some time this weekend to go through the MR and get it working :)

[iamjackg]

So I've spent a couple of days getting this working. It's mostly usable at a basic level, but only if there is only one client connected at any one time. In short, the code is able to push all (most) state changes from Terminator to tmux, but it's not able to react to changes made by either an attached tmux instance or other Terminator instances attached to the same session.

If your workflow only involves having one backing headless instance of tmux running at all times and connecting/disconnecting one Terminator instance at a time, then this should be fine.

There are a few really gnarly incompatibilities between Terminator's features and what tmux allows. As an example, in Terminator you can change the zoom level of all panes independently, which is impossible in tmux. Doing it leads to very odd behaviour where a terminal appears to have a certain height×width, but the backing tmux pane is actually smaller/bigger, and text wraps in odd ways in the other panes.

I'll do some more cleanup and submit a separate PR. Maybe we can still include it with some caveats. I wish I had a Mac to test how iTerm2 deals with all of this.

[mattrose]

I'm going to close this one, as we're now working on #408