Comment by philsnow | Hacker News Reader

Comment by philsnow | Hacker News Reader

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.

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.

This is much more awkward than just selecting it with the mouse. That's a reason to complain.

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.

idk what everyone else here is talking about, but I can copy with vertical panes with my mouse just fine http://i.imgur.com/lWxygYn.png

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.

Not necessarily. At least in Gnome-terminal, Ctrl-Alt-(mouse drag) is a block select that works just fine for copy-paste out of a vertical split.

Or do the rotation thing. Or do the copy-mode thing. More than one way to skin this cat; just depends on which workflow you wish to adopt.

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.

Like others have said, you don't use the mouse to drag & drop and copy. You use your keyboard, the way you would do it in your editor.

Select the pane. C-b z. Copy. C-b z.

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.

Woah. Just tried prefix-alt-[n], totally awesome.

Thanks!

C-b M-2 to rotate the panes into a horizontal split.

C-b M-1 to rotate the panes back into a vertical split.

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.

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.

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. :)

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.

> 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 swear I've had to install it before on Ubuntu. This would have been awhile ago though.

It's not on Ubuntu, and IIRC not on CentOS.

Debian Wheezy (and all Debians I've ever worked on prior). Not installed with a bare-bones server install.

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.

vi is present in Debian by default (though not the default $EDITOR)

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.

>> 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.

And I just tested it, too, and my terminal contents were restored. As they were with nano and emacs.

According to this page it is related to the smcup & rmcup capability: http://chenyufei.info/blog/2011-12-15/prevent-vim-less-clear...

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.

By [1] To turn it on add 'altscreen on' to ~/.screenrc

[1] https://wiki.archlinux.org/index.php/GNU_Screen

> Also how does tmux handle copy/paste with vertical splits?

This drove me nuts until I found block select. (Option-Command drag in OSX). That pretty much eliminated that problem for me.

Also prefix+z maximizes/restores a pane.

screen contents persisted through full-screen programs

The setting in ~/.screenrc that the article is missing is called "altscreen on".

Reply on news.ycombinator.com