Add support for tmux integration (like iTerm2)

Bug #1301605 reported by PreZ
208
This bug affects 35 people
Affects Status Importance Assigned to Milestone
Terminator
In Progress
Wishlist
Andrea Fagiani

Bug Description

iTerm 2 (only for mac) has full tmux integration. Meaning that iTerm 2 will communicate directly with the tmux server, and then enable things like native scollback and windowing that is directed by tmux.

ie. you split screen, rather than rendering by tmux inside the terminal window, iterm2 itself renders it as a split screen (or tabs, etc) , with full scroll back support, proper mouse copy/paste functionality (ie. triple-click selecting a whole line only does so within that pane), and essentially does all pane and scrollback management in iterm2 - but still being a tmux window. Which means one could attach to that session with a standard tmux session and it is identical.

This is an amazing feature, and is unparalleled by any other terminal app I've seen. Since leaving Mac and returning to Linux, I find myself sorely missing this functionality - especially managing scrollbacks and mouse copy/paste behavior with 'raw' tmux (ie. tmux managing panes by itself in one big window) is just painful.

This is not as big a deal when only working locally, but when you do a lot of work via. ssh, and move about - being able to re-attach to your tmux window is essential - and being able to have the terminal integrate properly while doing so is huge for productivity.

https://code.google.com/p/iterm2/wiki/TmuxIntegration

Related branches

Changed in terminator:
importance: Undecided → Wishlist
Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

OK, so I see it is based on "Control Mode" of tmux 1.8+. But the documentation is pretty terse, and as a non-tmux-user, I don't fully get what you're asking for. For those that do and for whom this is important, a good explanation of the "why", "what", and "how" should be posted for a discussion before going ahead. No point in doing a bunch of work if it causes so many other issues that it never gets merged.

Revision history for this message
PreZ (prez) wrote :

What I am asking for, is that things like the scrollback buffer and windowing that tmux has be 'exported' to the local terminal.

So if I use terminator to split screen, and it's "talking" to tmux, then that split screen is sent to tmux (so if I detached and re-attached, the same split screen would be there), and controlled locally (so clicking between splits switches windows).

The same goes for creating a new tab should be identical to creating a new pane in tmux, so that if I create 3 new tabs, and then detached tmux, re-attaching to tmux I would still have 3 new tabs (whether I connect via. terminator, or native tmux).

Finally, and most importantly, unification of the scrollback buffers. So when I use my mouse wheel to scroll, or shift-pgup/down, it shows the scroll back just like it does now - however that information comes from tmux (and is distinct per pane/split). So I don't have to do CTRL-B PgUp to scroll up my tmux buffer, and lack the controls I have from terminator - and if I use shift-PgUp it will work as expected, as opposed to being useless when using a tmux session.

But the long and short of it is, integrate with this 'control mode' of tmux so that the windowing and scrollback are unified between tmux and terminator and native terminator UI and key bindings just do their job, and affect the tmux session appropriately (and the terminator window can obtain it's state/scrollback when attaching to tmux). A local UI is much, much nicer to use than tmux via. SSH, but opening multiple terminator tabs, each having to ssh, and either each having to have their own tmux session making scrollback useless, or being suseptable to ssh disconnection problems (losing scrollback/etc) is terrible.

This is the problem iTerm2 solved by integrating with this control mode for tmux making it VERY nice to use, especially when logging into a remote session.

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Just in case I wasn't clear in my earlier comment, this is not something I'm intending on devoting time to any time soon. It sounds like a big complicated piece of work, and there are many many other things that need to be done. If you can find someone with the skill, time, and patience to implement this, I will be open to including it.

Revision history for this message
Dan Kilman (dank-n) wrote :

I've started working on a POC in which terminator acts as a tmux client (using control mode) as described above.
Before I delve into into it though, I wonder if you are aware of anyone that made some progress regarding this?
Another small question I have is regarding which version I should be using?
Currently, I'm implementing this on top of 0.98 although considering the experimental gtk 3 branch maybe I should switch to it?
If you think it won't be much pain migrating between them, I'll stick to 0.98 for now.
Thanks

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

I'm not aware of anyone else looking into this. If you do decide to take this forward put the bug into "In Progress" and assign it to yourself. That way others know that someone is already doing some activity on this.

A further suggestion is to create a personal branch, push it to Launchpad, and push incremental updates as you work. This has a number of positives, like allowing other people to perhaps collaborate with you, it lets me see what approach you're taking, and head off any bad decisions before they get too advanced (like making the entire terminal blink at 15 Hz). In the event that you cannot finish for whatever reason, it also lets others continue (standing on the shoulders of giants and all that). Sad to say that in OS sometimes people just disappear (I'm guilty of that myself) so occasional updates to a branch are a good "proof-of-life" without having to try and track people down.

As to which branch, **definitely** the gtk3 branch. The gtk3 branch is only experimental in that it is not the default by now. It is as stable as (if not more so) the gtk2 branch. The gtk2 branch is pretty much only going to get bug fixes from this point. Any new features and abilities will only go into gtk3, and gtk2 will gradually forgotten.

Revision history for this message
Dan Kilman (dank-n) wrote :

Thanks. I'll do just that.
It does imply a small learning curve as I've never really used bzr (mostly git). I'm also not sure how can I branch and push my branch to launchpad but I'll do some googling.

Changed in terminator:
status: New → In Progress
assignee: nobody → Dan Kilman (dank-n)
Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

The first three links here:
http://doc.bazaar.canonical.com/bzr.2.6/en/tutorials/index.html

Will get you up and running with bzr and pushing to a team branch in Launchpad.

Revision history for this message
Dan Kilman (dank-n) wrote :

Thanks.
I already pushed my changes to ~dank-n/terminator/tmux.
Can't seem to link this issue to that branch for some reason

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

To quote George Takei: Oh Myyyy!

That's some serious work there, Dan. Please don't take this the wrong way, but is that all your own work, or is it adapted from somewhere? I only ask to be sure of licensing. All contributions are necessarily assumed to be GPL v2 only, as per the applications license. There are some licenses (BSD, MIT mainly I think) where code could be adapted/used from another project, but it's just something I need to bear in mind.

When you think you're getting somewhere near to a point you'd like to get the first cut merged (I assume this is something that will have additions over time) there will probably be a bit of back and forth needed for my understanding. That way I know what the heck I'm writing to put in the manual :-)

I had a quick look (just curiosity) and I can see that is still a WIP, but I think I have a general feel for how you're plumbing the technical bits in. A little less clear for me at the moment is what the user experience will look like. I'll be watching with interest!

Revision history for this message
Dan Kilman (dank-n) wrote :

It's all my work. I didn't add any license headers to new files but I can copy/paste the license header from some other file in the project.

When I get to the point of mergeable code , I'll be happy to do that back and forth, but I think it will take some time for me to get there. There are many small bits to take care of to make this feature usable (to begin with). I'm also hoping I will not lose interest as time goes by (as sometimes happens).

Regarding the user experience, I must say I'm not sure about that one myself. The tmux models is close the that of terminator but now identical. In tmux, you can be connected to multiple servers (local and remote), in each server you can have multiple sessions, each session is a group of windows (tabs, in terminator) and each window has panes (split windows, horizontal, vertical, etc..)
Considering all that, many API/UX choices are to be made.

Revision history for this message
Jason Al-Mansor (jalmansor) wrote :

I am also very interested in this integration, as Terminator is the closest terminal Linux has to iTerm2, and would love to help with testing once a package is ready.

Revision history for this message
Dan Kilman (dank-n) wrote : Re: [Bug 1301605] Re: Add support for tmux integration (like iTerm2)

I have stopped working on this branch for some time now. I reached a very
buggy (albeit working) poc of an integration. There are still many things
to address. Anyone is more than welcome to take the work done so far and
move it forward.

On Sat, Sep 10, 2016 at 7:03 PM, Jason Al-Mansor <email address hidden>
wrote:

> I am also very interested in this integration, as Terminator is the
> closest terminal Linux has to iTerm2, and would love to help with
> testing once a package is ready.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1301605
>
> Title:
> Add support for tmux integration (like iTerm2)
>
> Status in Terminator:
> In Progress
>
> Bug description:
> iTerm 2 (only for mac) has full tmux integration. Meaning that iTerm
> 2 will communicate directly with the tmux server, and then enable
> things like native scollback and windowing that is directed by tmux.
>
> ie. you split screen, rather than rendering by tmux inside the
> terminal window, iterm2 itself renders it as a split screen (or tabs,
> etc) , with full scroll back support, proper mouse copy/paste
> functionality (ie. triple-click selecting a whole line only does so
> within that pane), and essentially does all pane and scrollback
> management in iterm2 - but still being a tmux window. Which means
> one could attach to that session with a standard tmux session and it
> is identical.
>
> This is an amazing feature, and is unparalleled by any other terminal
> app I've seen. Since leaving Mac and returning to Linux, I find
> myself sorely missing this functionality - especially managing
> scrollbacks and mouse copy/paste behavior with 'raw' tmux (ie. tmux
> managing panes by itself in one big window) is just painful.
>
> This is not as big a deal when only working locally, but when you do a
> lot of work via. ssh, and move about - being able to re-attach to your
> tmux window is essential - and being able to have the terminal
> integrate properly while doing so is huge for productivity.
>
> https://code.google.com/p/iterm2/wiki/TmuxIntegration
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/terminator/+bug/1301605/+subscriptions
>

Revision history for this message
Andrea Fagiani (andfagiani) wrote :

I have expanded upon the (amazing) work put in by Dan and uploaded a new branch with my changes at
https://code.launchpad.net/~andfagiani/terminator/tmux .

This is still very experimental, brace yourselves.

running "terminator -M" will start a local session (or attach to an existing one) named "terminator".
running "terminator -M --remote <something>" will start a remote session (or, again, attach to an existing one) named "terminator". <something> can be anything your user's ssh client would be able to connect to (Host entries in your ssh config, user@x.x.x.x, etc).

If you were to attach to an existing session, the initial layout is passed by tmux to terminator.

Outside of basic functionality, the following should work:
 - special characters
 - copy/paste
 - mouse scrolling (inside alternate buffers, otherwise it is handled by terminator)
 - zooming/maximizing a pane (they can be a little buggy due to gtk redrawing events, but they should be usable)

Not working, but hopefully one day:
 - tmux select-layout (especially useful for tmuxinator, tmuxifier, etc.)

Known bugs:
 - a few issues arise when using oh-my-zsh, e.g. non-working Home/End keys, non-working arrow-key history search, etc.
   it is probably due to this https://github.com/robbyrussell/oh-my-zsh/pull/5113 oh-my-zsh bug and there should be a workaround for most of them
 - un/maximizing a pane in alternate buffer mode (or entering it immediately after) can result in visual artifacts
 - probably many more

Feel free to try it out and report back any issues/bugs/suggestions you might have. As always, contributions are more than welcome.

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Hi Andrea, it's great that you've picked up where Dan left off. As you say it's still experimental I'm going to hold off on merging till you think it is as ready as you can get it without wider testing. You still seem to be plugging away at it, so I'm guessing we're not there yet.

As it's a *BIG* piece of work it'll need a good round of testing to be sure it doesn't negatively impact the non-tmux mode of working. We'll also need some good documentation so it's clear to everyone what this can do, and how to do it. This is as much for me as it is for users :-)

Good luck!

PS: I reassigned this bug to you, as you seem to be the active person right now :-)

Changed in terminator:
assignee: Dan Kilman (dank-n) → Andrea Fagiani (andfagiani)
Revision history for this message
Andrea Fagiani (andfagiani) wrote :

Hi Stephen,
indeed, the main concern is not to impact terminator's default mode of operation; I'm going through the code again and will try to remove any unnecessary interaction between the two.

There are still a few bugs I would like to address before considering it ready for merging; I'll ping you once the heavy lifting is done. Meanwhile I'll try to keep my branch up to date with the gtk3 branch, so our most brave users can consider testing both features at the same time.

Thanks,
Andrea

Revision history for this message
Ivan Avery Frey (doctor-pi) wrote :

Would it be possible to create a package for Debian unstable?

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Ivan, if you just want to test it out you do not need a package. Just branch Andrea's work:
bzr branch lp:~andfagiani/terminator/tmux
(optionally add a target folder name if you don't like "tmux")
then cd into the tmux (or otherwise) folder, and run:
./terminator
(add the -u flag if you are already running Terminator and have DBus turned on)

Until Andrea feels it is ready for wider release it will remain in this separate branch. The Terminator project won't be creating branch/distro specific packages, so it'd be up to some other kind soul.

Revision history for this message
@Spazm (granny-launchpad) wrote :

I tried andfagiani's lp. I found I could create a tmux session named terminator and then connect to it with `.terminator -M`. Terminator would correctly query the tmux server for the window layout. It was quite easy to lose consistency between the tmux session and the terminator session -- killed tmux panes did not close the terminator tabs. terminator tabs could crash without affecting the tmux beneath.

Is there a way to run tmux commands from the terminator window?

I want some level of integration, but I didn't really like the iterm tmux integration either. Really I just want native scrolling elements.

 It's a tricky problem. I'm glad you're giving it a go!

Revision history for this message
Georgi Boiko (pandasauce) wrote :

There could be an easier solution to this.

Adding a tickbox "tmux mode". When this tickbox is enabled, Terminator hotkeys could send tmux keystrokes instead of performing their normal function. Functionality that does not have a direct mapping to tmux could be disabled, and functionality that is present in tmux, but not in Terminator can still be invoked using tmux key bindings.

For example:

Ctrl+Shift+O -> Ctrl+B, "
Ctrl+Shift+E -> Ctrl+B, %

This should be much easier to implement than seamless integration, while providing a very close end result. Thoughts?

Revision history for this message
PreZ (prez) wrote :

Just to comment to @pandasauce, no, that's not really what this task is about. This task is about supporting tmux's Control Mode (aka. the -CC option of tmux) which allows a terminal to natively integrate with tmux, allowing for:

- Terminal rendered panes, tabs and windows (which can be detached and restored on re-attach)
- Local terminal scrollback (no ^B, page up, etc, just use the scroll bar / mouse wheel / keyboard shortcut of your terminal, same as a local non-tmux terminal). Which is also restored on attach.
- Intuitive selection - meaning that if I, say, have two panes vertically split, if I select a few lines with the mouse for copying, I get ONLY the lines in that pane, NOT the contents of both panes on those lines.

The only way to do that is if the terminal itself renders the panes/tabs/windows, and the only real way to do this is using the tmux -CC (control mode). Which iTerm2 does brilliantly, but is only available on OSX. Just putting in aliases for the ^B commands does nothing for any of those three goals, and could be done by the user themselves if that was what they wanted.

Unfortunately the tmux control mode is not very well documented, and unfortunately, the only answer otherwise is to read the source (https://github.com/tmux/tmux/issues/763). Which, I'll admit, is pretty shitty on tmux's part, however MANY people are clamoring for the native tmux (ala. iTerm2) experience outside of OSX.

That said I believe the bulk of the tmux code in question is here:
https://github.com/tmux/tmux/blob/master/control-notify.c and
https://github.com/tmux/tmux/blob/master/control.c

But I've not had a chance to look at it in depth, and my python skills (for terminator) are poor.

Revision history for this message
Felixoid (felixoid) wrote :

Hello. Just notification that there is a lot of people is waiting for this awesome feature.

I'm sorry for posting just '+1', but is there any chance to get this integration in some future?

Revision history for this message
Mario Manno (manno) wrote :

Hey, I rebased the (awesome) existing work and have it working with tmux 3.9a

You can run terminator directly form the repo, without installing. I also added TMUX.md with some very basic instructions: https://github.com/manno/terminator

Revision history for this message
Felixoid (felixoid) wrote :

Thank you @manno, that's an awesome job!

I have played with it a little bit and have feedback:

* The pane sizes from terminator to tmux isn't passed after the terminator restarted
* The formatting: custom background from tmux passed into terminator as italic
* The vim just don't update a window. So after an opening, I see only the first frame
* The names of tabs and panes aren't synced from terminator to tmux. I'm not sure if another way around works.

Thank you very much, that's amazing progress!

Revision history for this message
Felixoid (felixoid) wrote :

**upd to https://bugs.launchpad.net/terminator/+bug/1301605/comments/24**

The vim works if I didn't close and reopen terminator, but after this is done - doesn't anymore. So, most probably, the same error as in `pane sizes`

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.