While I find there are some good features from this change, my overall feeling is that this abstracts too far away from tmux. I attempt to use the same development environment across POSIX systems and this doesn't seem to feel right to me. YMMV
I've used screen for 15 years, am happy with the functionality, and don't see the need (yet) to switch to tmux. Given that, I would rather that iTerm2 not use more system resources supporting a vterm multiplexer that I don't use. It's not going to keep me from using iTerm, though.
You can modify tmux to use the same shortcuts as screen so that you can use the same muscle memory. I've been a heavy screen user for a while and recently switched to tmux. To me, tmux felt like a breath fresh air. That said, I spent the time (~hour) to convert my heavily modified screen environment over to tmux so I'm using pretty much the same shortcuts.
my understanding is that tmux has a cleaner code base, is more easily configurable, and is actively maintained. by comparison, screen is said to have stagnated, and have a convoluted code base.
for the moment, i continue to use screen, for the same reasons stated elsewhere: i'm familiar with it, and it's available nearly everywhere. but i'm not averse to experimenting with tmux
It isn't too clear what is going on, but what I've really wanted is Gnome-Terminal integrated with ssh+screen/tmux in such a way that I never need to know or care about how to use screen/tmux. Each "window" should just be a tab in gnome terminal with scrollback and menu commands behaving as appropriate. (I think something like this is what is described but I don't Mac.)
I do use Byobu which makes things a little easier. Of course you can argue that I should learn the ins and outs of configuring, magic keystrokes and using screen/tmux but I'd much rather use my brain for the other stuff (the actual work I'm doing). It should be possible to use something without having to know keystrokes and config files, discovering them from menus. Then when you do something often enough you can start using shortcuts and customization.
When I upgraded to OS X Lion, I discovered that the way that I had previously set up iTerm2 to launch tmux would cause a kernel panic when I would close iTerm2, without fail.
I don't remember off the top of my head what the setting was, but it was working in Snow Leopard on two different machines, and the kernel panic behavior struck on both upon Lion upgrade.
At any rate, changing how I had iTerm2 launch tmux solved the issue, but creating a guaranteed kernel panic like that was very odd indeed.
This is pretty cool, but definitely rough around the edges. When you tmux -C it uses your current iTerm2 window as a control window, then opens a new one for all of your tmux tabs. So I now have two windows instead of one per server. It'd be nice to have better UI for that.
Speaking of per server, it's only possible to map one tmux session per instance of iTerm2, which is a shame because I have a few.
There is also a special shortcut for new tab (cmd+shift+ctrl+RSI+t) rather than being transparent and just using the native key. I can't imagine I'll ever want to make a new local tab in the middle of a bunch of remote tabs.
Other than that, though, it works great and server-side installation was easy enough (get the tarball, apt-get build-dep tmux && ./configure && make && checkinstall). I've been eagerly awaiting this functionality for ages, and it's nice to see it finally happening.
This is really valuable feedback. Consider this the minimum viable integration. I'm going to iterate on the UI and bug fixes for the next few releases. After it's really stable I'll add support for multiple connections.
> I've been eagerly awaiting this functionality
> for ages, and it's nice to see it finally
> happening.
A few years ago there was a patch to GNOME Terminal that added similar integration with GNU Screen. The patch is probably too old to work at this point, and I generally prefer tmux to screen, but I thought that it might be worth mentioning.
> I can't imagine I'll ever want to make a new local tab in the middle of a bunch of remote tabs.
That's an interesting issue. I'd like to be able to, though I'd expect to use the normal tmux keys to create the remote tab--maybe that's too much to ask for.
I generally want only one window with a bunch of tabs on it. It would be nice it the tabs could be colored someway (subtly) so that I could tell which were local and which were connected to which servers.
I'm very excited about this--I hope the tmux patches get into the mainstream tmux code at some point. I haven't built the custom tmux on my server yet since I'm not sure I can use the new binary to attach to an already running tmux and I have too much state in my current one to restart. ;-)
yes. as per the post, you must download a patched version of tmux from the iterm site. they are trying to get the patch accepted upstream, but it hasn't been as of yet.
28 comments
[ 601 ms ] story [ 875 ms ] threadI don't think tmux and screen have a feature disparity, since tmux is basically feature complete when compared to Screen.
Same goes for most all well designed apps a lots of not well designed too: code pages are loaded into memory only when they are needed.
for the moment, i continue to use screen, for the same reasons stated elsewhere: i'm familiar with it, and it's available nearly everywhere. but i'm not averse to experimenting with tmux
terminator + tmux in vi mode works nice for me.
I do use Byobu which makes things a little easier. Of course you can argue that I should learn the ins and outs of configuring, magic keystrokes and using screen/tmux but I'd much rather use my brain for the other stuff (the actual work I'm doing). It should be possible to use something without having to know keystrokes and config files, discovering them from menus. Then when you do something often enough you can start using shortcuts and customization.
In other words combine a graphical terminal emulator and screen/tmux so that it is highly useful to perpetual intermediates: http://www.codinghorror.com/blog/2004/10/defending-perpetual...
I don't remember off the top of my head what the setting was, but it was working in Snow Leopard on two different machines, and the kernel panic behavior struck on both upon Lion upgrade.
At any rate, changing how I had iTerm2 launch tmux solved the issue, but creating a guaranteed kernel panic like that was very odd indeed.
Speaking of per server, it's only possible to map one tmux session per instance of iTerm2, which is a shame because I have a few.
There is also a special shortcut for new tab (cmd+shift+ctrl+RSI+t) rather than being transparent and just using the native key. I can't imagine I'll ever want to make a new local tab in the middle of a bunch of remote tabs.
Other than that, though, it works great and server-side installation was easy enough (get the tarball, apt-get build-dep tmux && ./configure && make && checkinstall). I've been eagerly awaiting this functionality for ages, and it's nice to see it finally happening.
split screen functionality in tmux is annoying but I hardly use it
That's an interesting issue. I'd like to be able to, though I'd expect to use the normal tmux keys to create the remote tab--maybe that's too much to ask for.
I generally want only one window with a bunch of tabs on it. It would be nice it the tabs could be colored someway (subtly) so that I could tell which were local and which were connected to which servers.
I'm very excited about this--I hope the tmux patches get into the mainstream tmux code at some point. I haven't built the custom tmux on my server yet since I'm not sure I can use the new binary to attach to an already running tmux and I have too much state in my current one to restart. ;-)