Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Workflow in tmux

coderwall.com

Post reply on HN
Print view View original

31–40 of 62 posts

Re: Workflow in tmux

#31

Post by d0m »

eridius wrote: post #28
d0m wrote: post #27

I started using tmux.. then switched to stumpwm which is too awesome to explain here. Embrace the full power of emacs and your Window Manager.

stumpwm is a window manager. tmux is a terminal multiplexer. They are not the same thing and using one does not preclude using the other.

*Started using tmux, then realized for my needs stumpwm was better. Obviously these are two different beasts. I still often use tmux on remote server for instance. However, if you use tmux locally, then a tiling manager might be better.

Re: Workflow in tmux

#32

Post by emidln »

Osiris wrote: post #23
joelhooks wrote: post #21

Earlier quoted context omitted.

it is lightweight, contained, and excellent if you have a "unix-like" workflow. Typically I'll have a watch script, server, and vim in a given window, and it is super compact. Some cons are probably the learning curve required to see any advantage, and the fundamental lack of any respect for mousing, which can be in the pro column for many.

That's interesting. I practically never use the mouse to switch between windows in OS X or Windows. The biggest problem I have with tmux is vertical splits don't work with native copy-paste because the selection goes across both panes. Using multiple terminal windows, on the other hand, doesn't have that issue.

Native copy/paste typically requires a mouse. using tmux's copy-mode and pasting doesn't require a mouse an still stays inside panes.

Re: Workflow in tmux

#33

Post by marshray »

vec wrote: post #3
swah wrote: post #2

OT: Tmux/Screen are a little bit RSI inducing to me, to be used effectively. Any tips?

Remap caps lock to be a ctrl key, then preferably remap your prefix key to a. Caps+a is way easier to type.

Ctrl+L is good because it's on the home row and typically used for uninteresting stuff anyway (like refreshing the terminal window).

My sequence to actually refresh the window is "Ctrl+L L"

Re: Workflow in tmux

#34

Post by tomsthumb »

swah wrote: post #2

OT: Tmux/Screen are a little bit RSI inducing to me, to be used effectively. Any tips?

Remap your keys. Capslock makes for a very nice control key, cause really, that's the single most used modifier/power key that gets used aside from maybe shift. You can also remap the "lead-in" character.

I use ^j on both screen and tmux (tmux isn't on our prod servers). This frees up ^a in screen so ^a can send me to the beginning of a line, which is quite nice as I write a lot of long commands and it works in several different programs. It's just a really easy combo to hit that avoids chording or stretching your hands to do something like that constantly. My right hand does not hit the 'b' key for squat.

Honestly, a lot of stuff is configurable so that with some thought and planning (and knowledge and research) you can relieve a lot of weird movements with your hands.

Re: Workflow in tmux

#35

Post by chirayuk »

rogerbinns wrote: post #22

The single most irritating thing about tmux is that viewers have to look at the same window or whatever it is called. My typical usage pattern is to connect twice, have one window where there is a long running task I want to monitor and a second where I am typing commands. But I can't show one in one connection and the other in the other connection. Note that I use byobu to front end things, and when using screen thi…

I believe tmux 1.8 supports this use case.

From the manpage (for new-session):  If -t is given, the new session is grouped with target-session.  This means they share the same set of windows - all windows from target-session are linked to the new session and any subsequent new windows or windows being closed are applied to both sessions.  The current and previous window and any session options remain independent and either session may be killed without affecting the other.

Re: Workflow in tmux

#36

Post by chirayuk »

base698 wrote: post #15
illicium wrote: post #13

Earlier quoted context omitted.

What's wrong with using reattach-to-user-namespace?

It involves compiling native code and its easier to do with a shell script?

I know what you mean. I translated that to a python script a while ago for myself so I could stick it on other boxes without having to compile it. It's now a gist – https://gist.github.com/chirayuk/5377283

Re: Workflow in tmux

#37

Post by yungchin »

Osiris wrote: post #19

I understand using console window managers when logged into a headless system where you don't otherwise have access to a UI, but I'm baffled by the desire to use console-based window managers within well defined GUI like OS X. In OS X, there are multitudes of tools to allow you to manage windows. Spectacle is a simple one, Slate is extremely customizable. Why not use the built-in OS X window manager to manager variou…

As the article concludes: "These tools are powerful not because you can use the keyboard instead of a mouse, they are powerful because you can combine them in new ways" (for context: through tmux-prefixed commands, your scripts can talk to your terminals). But more importantly, if you don't think of it as a replacement for a window manager it makes more sense - it's "only" a terminal multiplexer. You'll still have need/use for a great WM, too.

Re: Workflow in tmux

#38

Post by rogerbinns »

pyre wrote: post #29
piinbinary wrote: post #25

Earlier quoted context omitted.

I always have two copies of tmux running, for this very reason. Someone out there surely must have a better solution.

I used to do this all of the time in screen, but I haven't done so since switching to tmux (haven't run upon the situation). You've inspired me to look into it. First, terminology. I know that tmux has: servers, clients, windows, sessions, and panes, but I've never bothered to understand how they fit together. * server - The server is a process that listens on a unix socket, and accepts connections from clients. Each…

This is so much more complicated! When using byobu I use F3 and F4 to cycle to previous and next window. I can't understand why they think that by default I want all of the viewers to switch at once.

Re: Workflow in tmux

#39

Post by sathish316 »

th wrote: post #24
eridius wrote: post #16

Earlier quoted context omitted.

The status bar with the arrow breadcrumbs _looks like_ powerline. If you read his tmux config, he's not actually using powerline, he just duplicated the appearance.

He is using the vim-powerline bundle for vim, but it looks like you're right about the tmux config.

tmux has its own powerline: https://github.com/erikw/tmux-powerline

Re: Workflow in tmux

#40

Post by Sodel »

chirayuk wrote: post #35
rogerbinns wrote: post #22

The single most irritating thing about tmux is that viewers have to look at the same window or whatever it is called. My typical usage pattern is to connect twice, have one window where there is a long running task I want to monitor and a second where I am typing commands. But I can't show one in one connection and the other in the other connection. Note that I use byobu to front end things, and when using screen thi…

I believe tmux 1.8 supports this use case. From the manpage (for new-session): If -t is given, the new session is grouped with target-session. This means they share the same set of windows - all windows from target-session are linked to the new session and any subsequent new windows or windows being closed are applied to both sessions. The current and previous window and any session options remain independent and eit…

I've started running tmux in all my terminals automatically, and conveniently sharing a "master" session between them all.

Instead of running tmux directly, I have a small script which creates a session named TMUX-MASTER if it doesn't already exist, and immediately detaches it. All the clients that I actually interact with are created separately and automatically grouped with the TMUX-MASTER session.

To prevent my system from being clogged by dozens of detached client sessions, I rebound prefix+d to kill-session, killing the client session but leaving my TMUX-MASTER session untouched. Closing terminals while running these client sessions, however, still leaves my system cluttered with dormant client sessions.

I'd like to see if a "ephemeral" option (it'd need a better name) could easily be added to new-session, which would cause the created session to just die when it's told to detach, or receives the HUP signal. It'd simplify things a bit.

Post reply on HN