I feel like I'm the only one taking crazy pills whenever this topic comes up.
Granted, tmux has a better configuration language.
However the whole session/window/pane/instance model is bizarre, as evidenced by the secition "Multiple Clients Sharing One Session" under "common problems" in the linked article.
On top of that, the below are all given as points in favor of tmux, but they're either arguably better in screen or else a wash:
> Better redraw model
This is one of the (many) things that drove me back to screen. The two times I tried tmux, it had exactly this kind of issue where it would fail to redraw the screen correctly after SIGWINCH.
> screen contents persisted through full-screen programs
doesn't this depend on whether the program calls curses endwin() function ? why does tmux/screen need to know about this ?
> not possible to remove the visual bell from Screen completely
doesn't this work?
vbell off
bell_msg ""
though I'm not sure why you would want to do such a thing.
> automatic window renaming
last I checked this used a huge amount of cpu. is that no longer the case ? in any case, I name my windows according to what i'm doing in that window, since "bash" or "screen" (I use nested screen sessions) or "emacs" is not a useful window title.
> vertical splits
newish screen does this. I don't see the use. I figure I either have a roughly 80-column screen (default linux virtual terminals) or it's wide enough to have multiple 80-column windows (laptop or desktop running X). If I have enough horizontal space, I'm using a sensible window manager that is better-suited to real estate management.
Also how does tmux handle copy/paste with vertical splits ?
> vi key bindings in copy mode
is this supposed to be a win for tmux over screen ? both basic emacs and vi movement works out of the box in screen.
I'm with you. I tried tmux but didn't find any benefit and several serious drawbacks.
Many of the purported benefits - better configuration language, more maintainable code - don't matter to me:
- Screen is done and isn't going to change. Debian has had the vertical splits patch for so long I was surprised it was a patch.
- My configuration of screen is not going to change. It's five lines that I copied and pasted 10 years ago. There's just not that much that needs to be configured.
The "Multiple Clients Sharing One Session" thing is important to me and screen gets it right by default. It's useful to have a few fixed xterms on my screen and a bunch of multiplexed terminals in screen. I use one screen session per task.
I think "screen contents persisted through full-screen programs" is screen's "altscreen on" setting. Or at least that's my note from the person whose screenrc I stole.
> Also how does tmux handle copy/paste with vertical splits ?
It doesn't. If I want to copy some text and it's in a vertical split, well... shit. Time to break out the tmux manual and see if I can figure out how to move this pane above the other one. You know what, screw it. I'll just open a new window entirely, and re-run the test there so I can copy the output.
That's how tmux handles copy/paste with vertical splits.
Huh copy/paste works fine with vertical splits. Just setup tmux to sync your tmux clipboard with your regular x (or osx if you're into that kind of thing) clipboard.
You mean selecting text with a mouse on a vertical split? If so get tmux upgraded to 1.8+ then prefix-z and you can temporarily zoom the window to full screen.
Your information on tmux is highly out of date.
Also prefix-alt-2 will move to horizontal layout of panes.
Yes, the zoom feature (resize-pane -Z) is a game changer for tmux-to-system-clipboard workflows. Before that I would do the block select with my mouse and then weed out all the extra whitespace as needed later.
Both screen and tmux support a feature you'll really love. Upon hitting ctrl+a/b [, both enter a "copy mode". This allows you to both scroll through the history, and to copy text from a specific pane.
I may have misunderstood what you meant, but copy and paste in tmux works in vertical panes just the same as horizontal panes: http://d.pr/i/93p2/wNHyqVFr (copied from the right shell into vim in the left).
I think he's asking what happens if you have two panes side-by-side and try to select text in one to copy. Does it also select text from the other one?
If you use a mouse yeah, but as noted by others, with tmux 1.8+ just prefix-z and you can temporarily zoom that one pane. So there really isn't much reason to complain about this particularly.
Well, this is not really the dilemma though. If you don't have vertical splits you don't have this problem, but you also don't have vertical splits. If you have vertical splits you'll solve this problem somehow.
They're talking about using the host terminal's text-selection mode and the system clipboard, rather than tmux's built-in text-selection mode, which does.
I too generally use tmux's built-in text-selection and clipboard when I'm copying from pane to pane, because it's more convenient.
The thing is you can synchronize tmux selection with your clipboard, there isn't really a need for tmux to "support" your terminal's view of tmux running within.
The answer is, it depends. If you copy it with the mouse, you will be copying both sides. If you copy it with your tmux keyboard copy bindings, it will copy just the one side. I don't know the default bindings because I made mine prefix-esc to get to copy mode, vi keys, v to select, y to yank.
Every 4-6 months, after reading some articles about tmux, I get the urge to try it again. And I always come back to screen for many of the same reasons (and the fact that it's not on a lot of systems by default).
The session/window/pane/instance thing is definitely confusing and not well explained. I think it's even worse if you already have a lot of screen experience.
From my experience screen isn't on a lot of systems either. Usually the admins that I work with are willing to install both/either at request.
screen has the equivalent to sessions as well `screen -ls` will show them whereas `tmux list-sessions` will show the tmux ones. A window is composed of panes (analogy from physical windows, pane of glass). An instance is one user on a session.
Very much depending on what sort of installation (not the distro itself) you've got. Most of Minimal installation doesn't come with screen nor tmux by default.
> From my experience screen isn't on a lot of systems either.
Can you name one distro that doesn't include it by default? In my experience you can rely on just about every system having a core set of utilities: bash, vim, screen, ssh etc.
I'd cross both vim and screen off that list. I know Debian doesn't come with vim installed by default, and uses nano as it's editor. Sure it's trivial to install, and many admins install it the first thing they do, but it's not there by default.
I agree with you that if you have to work with multiple systems where you do not have control over installing packages, you might be better off to use pre-installed screen and vi with default configs so you can get right to work.
But if you have your own workstation and do most of the work with this workstation, tmux + customized configs might be a viable option.
It just depends how good your muscle memory will keep up. :)
>> screen contents persisted through full-screen programs
> doesn't this depend on whether the program calls curses endwin() function ? why does tmux/screen need to know about this ?
I just tested out of curiosity. Running vim and exiting in tmux reverts to the previous screen contents, like in raw urxvt; in screen, the previous screen contents are lost. I do not know why.
This is a weird feature called a "secondary screen", which means that the terminal secretly has a second buffer to draw ncurses programs on. The OP probably had this disabled in screen, so it didn't work in their terminal.
That looks wonderful! Being able to place the config files in project folders is a great idea. It always annoyed me when I forgot to backup the magic config folder in tmuxinator when moving machines.
> a) A single keyboard shortcut to navigate between both panes and vim windows in a single tmux workspace:
Oh man you got my hopes up. This would be lifechanging if my tmux session was running on the same machine that vim was running. "#{pane_current_command}" is almost always ssh for me.
In one of the recent releases tmux switched from starting new panes in $PWD to $HOME. I am sure they had their reasons but the new behavior is terrible for me. To get the old behavior back (AKA new pane in current working directory) add the following to ~/.tmux.conf
Are you sure its $HOME? I think it's just the dir you load your session in. I just opened a new tmux session in ~/Dropbox and all new panes open in ~/Dropbox. So do my windows.
Cool setup, though I personally hate using Ctrl-A for the prefix. I am too engrained to that being beginning of line. I use Ctrl-O since that doesn't seem to interfere with anything major.
I started using tmux about 2 years ago and don't know how I lived without it.
I've always found the backtick (`) to be the most convenient for me. I can hit it easily with my left hand ring finger and I don't have to type backticks too much as I typically use $(command) for command substitution.
Agreed. I fell in love with Tmux from the moment I realized it used <C-b> as the prefix. Still accessible with just my left hand (especially since I map Caps Lock to Ctrl), but doesn't block a commonly-used chord.
Ctrl-a a gets you to beginning of line.
My problem is that I'm so used to that combo that on the rare occasions that I'm not in a screen/tmux session, I keep putting "a"s at the start of the line.
Note that maximum-awesome is for/by the vim crowd -- who could not care less about Ctrl-A being move-beginning-of-line but do want continuity with screen's prefix-key.
Can someone explain the benefits of using tmux or screen or something similar over opening multiple terminals in a tiling WM?
The two arguments I could see are resource usage (not an issue on modern machines) or detach/attach (which is a huge benefit when working remotely, but I don't see any gain locally). But other than those, I don't see any benefits to having a second tiling system sitting on top of my current tiling system.
Xmonad user here.
Sessions are wonderful. I can run one just for xmonad as a job (I like to hack that config quite often ). Another just for my VPN script (which puts out I/O stats every few minutes).
And per project, I'll have a few. Say I have one where I have one shell for compilation, one for version control, and two for testing. Give each one a prefix for the project, and I've got all that separated out. E.g.: Two projects: foo and bar: foo-compile, foo-git, foo-test-a, foo-test-b, bar-compile, bar-git, etc..
Now, I have clean shell histories (and scroll buffers) for each. I can ssh into each one as I want, and reuse my terminal windows. This latter bit helps keep my already-complex-enough window setup manageable.
1. You might not have a tiling window manager in the first place (there are no decent ones on OS X that don't require manual operation to my memory).
2. You work on a remote machine and prefer to have your window layout remembered there, so it can instantly be restored no matter what computer you're physically working on, whether or not it happens to have or even support your favorite tiling window manager.
3. It's simply easier for me to do everything within one terminal window full-screened on a 27 inch monitor. It's less context switching.
I completely agree with 1 and 2 - my question was related to a local machine with a tiling WM.
For 3, can you elaborate? How is it less context switching? You're doing the same set of operations in both settings - switching, moving and resizing terminal windows (whether real or virtual).
For those who find tmux a bit arcane and screen a bit too primitive, I've found dvtm+dtach to be an excellent terminal multiplexer and session manager.
"abduco is in many ways very similar to dtach but is actively maintained, contains no legacy code, provides a few additional features, has a cleaner, more robust implementation and is licensed under a BSD style license"
My one gripe about tmux is that when doing things like `git commit` where it will open my editor (ST2), after I close the editor, tmux never realizes the file has been closed, so it just hangs there. If I do the exact same command outside of tmux, it doesn't.
Two issues in tmux not fixed or this way by design are missing flow control and that you have to explicitly bind shortcuts which work in gnu screen automatically without pressing Ctrl twice. Other than that it's good.
"without pressing Ctrl twice" should be "without pressing the binding while not holding down Ctrl". Quickly pressing C-b c in tmux while still holding down Ctrl doesn't work without an explicit binding and it does in gnu screen.
This is very strange, could you describe he problem more? Also, does the contents of an ncurses app (vim, less, emacs) stay after you close the program?
When I use less in a tmux or screen session to view /var/log/syslog et al, when I type -S to chop long lines it continues to wrap the line instead of chop it.
Granted, tmux has a better configuration language.
However the whole session/window/pane/instance model is bizarre, as evidenced by the secition "Multiple Clients Sharing One Session" under "common problems" in the linked article.
On top of that, the below are all given as points in favor of tmux, but they're either arguably better in screen or else a wash:
> Better redraw model
This is one of the (many) things that drove me back to screen. The two times I tried tmux, it had exactly this kind of issue where it would fail to redraw the screen correctly after SIGWINCH.
> screen contents persisted through full-screen programs
doesn't this depend on whether the program calls curses endwin() function ? why does tmux/screen need to know about this ?
> not possible to remove the visual bell from Screen completely
doesn't this work?
though I'm not sure why you would want to do such a thing.> automatic window renaming
last I checked this used a huge amount of cpu. is that no longer the case ? in any case, I name my windows according to what i'm doing in that window, since "bash" or "screen" (I use nested screen sessions) or "emacs" is not a useful window title.
> vertical splits
newish screen does this. I don't see the use. I figure I either have a roughly 80-column screen (default linux virtual terminals) or it's wide enough to have multiple 80-column windows (laptop or desktop running X). If I have enough horizontal space, I'm using a sensible window manager that is better-suited to real estate management.
Also how does tmux handle copy/paste with vertical splits ?
> vi key bindings in copy mode
is this supposed to be a win for tmux over screen ? both basic emacs and vi movement works out of the box in screen.