Hacker News new | past | comments | ask | show | jobs | submit login
Tmux 1.9 released (sourceforge.net)
182 points by jc79 on Feb 21, 2014 | hide | past | web | favorite | 117 comments

I have to say that the tmux-users mailing list in general, and Nicholas Marriott in particular, are really nice and friendly.

I had a feature request (256 colors in fbterm so you can get 256 color tmux/vim without x), quickly got patch code, got support (I had never used patch before and didn't tell it to ignore whitespace) and when it worked, was told it would be in 1.9, and there it is. :-)

Just spent half an hour trying to figure out why 256 color mode stopped working in Vim.

I'm blaming you =P

In all seriousness actually trying to get 256 colour mode auto detecting and working reliability across different xterms, tmux/screen, ssh and so on, without some hack that forces the 256 on even when it's not supported seems impossible :/

I added the following to my zshrc, which seems to have helped. Why don't these terminals report 256 color mode by default?

    if [ "$COLORTERM" == "yes" -a "$TERM" == "xterm" ]; then
       export TERM=xterm-256color

The escape sequences to set 256 colors were previously hardcoded into tmux, instead of detected from terminfo. That works fine, until you use a program that uses different escape sequences.

I suspect terminals don't set 256 colors by default for backward compatibility reasons. tmux itself didn't assume, you needed something in your config file or a command line option. Now though, I believe it can detect it based on your term.

An absolute staple of my development setup, and one of those rare tools that always just seems to work. Thanks for all the work!

Sidebar: if you're a die-hard tmux user in Linux, and you do something like, say, open vim and then realize you haven't opened it in tmux, check out https://github.com/nelhage/reptyr - it lets you do things like ctrl-z to background vim, start tmux, then steal the vim process into your new tmux session. Pretty cool!

I love and use tux all the time, but for me it doesn't always just work. I regularly run into weird backspace/delete behavior when using tmux with ssh. For example, ssh from ubuntu into rhel and then running tmux will give me a completely different behavior compared to when I tmux in ubuntu and then ssh into rhel. I know that backspace/delete behavior has more to do with the terminal than tmux, but gnome terminal seems to handle it fine outside of tmux.

I've run into this a few times, too -- seems to have something to do with the termcap info for tmux's virtual term. FWIW, I was able to work around it with 'stty', e.g.:

$ stty erase ^?

to recognize DEL (ASCII 127, or ^?) as backspace. I have that in my .bashrc on a particular machine that gives me this problem...

Hmm, I remember having this issue with RHEL also, but I thought it was fixed in maybe tmux 1.8... although I could certainly be wrong.

Installed it today for the first time (just switched from Windows to Ubuntu) and I love it already!


Thanks for the useful tip. I also really appreciate the power and utility of tmuxinator. [1]

[1] https://github.com/tmuxinator/tmuxinator

I remember using on the mac a branch of tmux with iTerm, where the gui understood tmux, giving native tabs and scrollback. I thought this was the greatest thing ever, but am now on Linux. Is this work still continuing does anyone know?

This actually works with GNU Screen. Because of this, and because of the lack of workspace reordering in tmux, I seem to be actually about the only person who likes Screen more than tmux.

> because of the lack of workspace reordering in tmux

What do you mean? Commands like tmux swap-window and tmux move window allow you do move the order of the windows / workspaces.

See this discussion:


It kind of works in the end, but it's arguably a bit more awkward to use than in screen.

Your right, I remember that discussion: I actually use pier solution, with the shellscript (I assigned them to Ctrl-A + Number)

I agree that it does not work 'out of the box', but once setup, it works quite nice :)

I'm a screen die-hard. tmux is probably lovely but since it's not on 100% of the machines I use, it's not going to get any traction with me.

You're not! I work on a team of Screen enthusiasts. We all use it, every day.

Why not just keep your key bindings compatible with screen? You can't stay with legacy systems forever.

There really isn't anything 'legacy' with screen. I've been using it for 20 years daily. I really have no reason to switch to tmux because I really can't see anything screen doesn't already offer me.

Vertical splits were patched in and added a long time ago, screen is usually installed by default, so I know it is there on systems where I'm not allowed to install packages. I can share screen sessions with co-workers, split windows etc.

> Vertical splits were patched in and added a long time ago

IIRC, that patch floated around for a while.

The other thing that tmux brings to the table is better scripting support than screen + things like tmuxinator (for me at least).

Isn't one of the advantages of tmux is reduce / avoid using the mouse?

I know that scrolling is one of the first non-obvious changes that seem irritating at first. But after you get used to scrolling with the keyboard, I find myself missing this possibility on 'standard' terminal windows.

Suddenly using the mouse to scroll feels really awkward and inefficient.

I think I can live without scrolling, but what I found most irritating when trying tmux is selecting / copying / pasting things. ATM I use iterm with split panes and a 'quake-style' dropdown terminal; tbh it works well enough for me.

you can scroll just fine in tmux, in fact better because you can search in your scroll back. <c-b>[

as for selecting copying pasting. i use these options

    set -g mouse-resize-pane on
    set -g mouse-select-pane on
i can now select and resize panes with the mouse, and i can select while holding the option key on the keyboard.

also if you set

    setw -g mode-mouse on
you can scroll back with the mouse in the scroll back buffer without having to press c-b[ and it will still properly scroll everywhere else... vim/weechat/etc.

on a mac, iterm2 does this natively(in linux it works anyway). but if you want to use that in terminal or totalterminal(quake term) you'll need to install mouseterm. I recommend using mouseterm-plus as i recall mouse term is no longer maintained.

edit: looks like the link is dead you'll have to build it yourself https://github.com/saitoha/mouseterm-plus

If you happen to be copying with the mouse, tmux has prefix + z, which expands your current pane to fill the screen. prefix + z returns the screen layout to it's former self. Makes the need to copy easy regardless of layout.

Why can't you have both efficient mouse AND keyboard control?

Sometimes your hand is on the mouse and it makes for sense to use it.

You might like Plan 9.

Depends. If you have a ThinkPad with a TrackPoint-style mouse, it's actually really convenient having a mouse in the home row. Hold the middle button and scroll up/down easily.

Really? I find a quick scroll of the mouse wheel easier. Also when scrolling back a few hundred (or thousand lines), grabbing the scroll bar and finding where I want to be I find much faster.

I don't mind people who don't want to use the mouse, that's fine, but personally I sometimes don't run tmux when I know it will upset my scrolling and cut+pasting.

C-b [ + C-r <string> is pretty awesome when you know what you're looking for in the search history... Though I definitely use wheel scrolling when I don't remember exactly what I'm looking for or looking at log output.

I don't understand what are you talking about. In almost every linux terminal you can scroll with PageUp/Down and with mouse on most X ones(ex.: rxvt, xfce-terminal). In tmux one can press ctrl+b -> PageUp and scroll with keyboard or mouse.

edit: corrected hotkeys

There are other benefits to having GUI integration to your terminal emulator. One of which is discovery of features. I personally find it easier sometimes to discover new features that are available in a context menu as opposed to reading an entire MAN page.

Mouse vs keyboard: I navigate with whatever my hand is on at the moment.

Works out the box with tmux 1.8 and later + iTerm2 these days. Simply run tmux -CC [attach] and the tmux session pops up as tabs in iTerm2. I don't know about any similar alternatives for linux :(


The part that I dislike about it is that:

1) You have to have a separate terminal window for the 'control' process.

2) Now creating new tabs / windows automatically creates them in said tmux session (unless you manually use the "Profiles" drop-down menu). It would be nice to use Tmux as a way to create a window full of tabs in a scripted way (a la Tmuxinator), but not be forced to use a single Tmux session for everything.

Can someone share a use case or example of using tmux? Sorry for being thick, but I'm just not getting it.

I use iTerm. I use ssh to regularly access about 20 other boxes. I create tabs for every task. So I might have 3 tabs for a single box. 1 to start/stop processes, 1 to edit files, 1 to tail logs to verify my crap's working.

I installed tmux and I couldn't figure out what I'd use it for. This might be completely wrong, but I thought it'd allow me to control multiple boxes from a single session.

For example, I have 5 production servers that set up the same way. I want to do the same thing on all 5 at the same time. So my input/output is multiplexed to 5 boxes in a 1:5 relationship. Only I couldn't get that to work. I got lost switching sessions/contexts.

Again, sorry for being thick. I feel like I'm missing something great here.

One use case: you are working away on a server via SSH at some café and suddenly the a internet dies on you. Oh crap, you had a ``make install`` running and now it will be half-baked because a dead SSH connection will HUP the process you were using.

With tmux, no HUP happens on the server side so the process keeps running. Once your internet connection comes back online you ssh back into the machine and ``tmux attach`` to the previous session. And voilà, it is like nothing happened. All of your output from before is still there too.

Not sure if you tried following for input/output multiplexing - * Create 5 panes, one for each server * Ctrl-b :setw synchronize-panes

This should synchronize the input to all panes i.e. type in any one and it will be sent to all 5. to turn it off, just run the same command again. I don't know if tmux has equivalent synchronize-windows.

My use case for TMux is simple:

It is always persistent so you have your tabs all set up on each server. You just attach to the sessions of TMux on the servers and don't have to ever create your complex scheme on your local machine. You can have them start on boot on the server and just attach to them via ssh.

My case I use WeeChat (IRC) on my home server always running and I just ssh to my server and attach to that session.

Yup, it was merged into trunk for 1.8. I love iTerm/Tmux integration.

but is there also an integration for a Linux terminal emulator?

Not as far as I know. The iterm2 - tmux integration work was done by the iterm2 author George Nachman.

You can also get tab and scrollback support in the regular mac terminal with mouseterm https://bitheap.org/mouseterm/

If you're on Windows, ConEmu offers the same functionality. And as a bonus you can also run windows apps inside the terminal window.

Here's how it looks http://i.imgur.com/dEpQYJf.jpg

And now you can use tmux in Cygwin.

I've been using it in Cygwin for a long time. What is supposed to be broken?

That's strange. The patch that allows it to work has only existed for less than a year. Tmux apparently passes file descriptors over unix domain sockets, which isn't supported by Cygwin.

Well by long time I mean several months. Happy coincidence I guess.


Check the changelog again. Normal changes, point #4:

* Tmux now runs under Cygwin natively.

i highly recommend transparency about 85-90% on conemu if you use black/dark backgrounds. it really seems to save me some alt-tabs especially when following instructions.

I just wanted to say thanks for the hard work! I absolutely love this tool. About 1/2 of my team has started using this tool since I introduced it to the group and everyone of them loves it.

I started using tmux just because I was frustrated that I would occasionally kill the terminal with Command + Q instead of just the current window Command + W. But now there is just so much of tmux that helps my daily work flow I don't know how I ever got by without it.

> 'default-path' has been removed

This kind of annoys me, but I'm successfully using this workaround (hinted at in the announcement):

bind c run 'tmux new-window -c "#{pane_current_path}"' bind-key '%' split-window -hc "#{pane_current_path}" bind-key '"' split-window -vc "#{pane_current_path}"

Anyone know why this change was made?

For anyone else who shares tmux configs between different versions, this is a good way to do it:

    if-shell "[[ `tmux -V` == *1.9* ]]" \
        'unbind c; bind c new-window -c "#{pane_current_path}"'

No, but I am very thankful for your posted workaround.

Thank you! a Great piece of software that I use constantly. The world is better place with developers like you. Go on and hug yourself.

Has anyone used these, and can they give me a comparison: tmux/scree/byobu

Currently a byobu user, it seems fine so far. Wondering what others offer more than that.

I use screen and tmux for different tasks.

I'll use screen when I need to run a long-running task and can't keep my terminal session open.

I use tmux with a script so that I can ssh into multiple nodes and broadcast the same commands to them all at the same time. Great for interactive deployments that I haven't been able to automate away with CFEngine just yet.

So why do you use screen rather than tmux for long running tasks, if you use tmux for everything else?

Force of habit more than anything else. I just learned about tmux a month ago when I needed to find a way to implement that broadcast solution. For the moment, broadcasting is the only thing I use tmux for - Just as detaching from long running sessions is the only thing I use screen for. I don't have an allegiance to either as most of my tasks I do in a single terminal window.

> I use tmux with a script so that I can ssh into multiple nodes and broadcast the same commands to them all at the same time.

I sometimes need to do this with multiple VMs. I'm really, really not in favor of bash scripting, but I've found the following to suffice, without the tmux dependency:

    for host in box1 box2 box3; do ssh $host 'command; command; command'; done
(This presumes you've set up ssh-agent or are using passphraseless keys and suitable stanzas in ~/.ssh/config; adjust to taste if not.)

I'd never heard of using tmux in this fashion before. Is it that the task sufficiently resembles a nail, or does tmux provide some unique benefit here?

That tmux broadcast trick sounds interesting. Are you able to provide some more details about it please?

Pull up the command line with "Ctrl-b :" Synchronize your panes: "setw synchronize-panes on" Now you can send the same commands to all panes in the current window. To turn synchronization off: "setw synchronize-panes off"

My shell script takes in a list of tuples (hostname plus a special id that I need to paste for my tasks that's unique to each host), splits off a window pane for each hostname(tmux split-window -h), ssh's into each host in it's own pane, and turns on synchronization.

I did a little trick to setup pastebuffers to hold that special id from the tuple i passed in. And setup keybindings so that I can press a key combination to paste in that ID whenever I need it to each respective pane.

If I ever need to temporarily remove a pane or several panes from the syncronized session but keep the others synced, I just change focus to the pane I want to unsync and put it into copy mode with "Ctrl-b [". Can take the pane back out of copy mode by hitting "q".

So far it's made me much more productive when I have to run a bunch of identical commands on a cluster of nodes for which we have no defined process (i.e. I'm figuring it out as I go).

I'll need to sanitize the script, but I'll try to put up a github gist of the script later on.

Thanks for that :)

> I'll need to sanitize the script, but I'll try to put up a github gist of the script later on.

If you wouldn't mind, I'd be hugely grateful as I often find myself having to do similar tasks as what you describe (and even wanted to set up a script to auto start sessions in different panes like you do but wasn't aware that was possible).

While I do use tmux quite heavily (to the point where I found myself needing to rebind a lot of the keys to be more vi like or more convenient to manage one handed), I reckon I still only use about 10% of it's functionality. So it would be good to see other solutions based around tmux.

So, for those looking to make synching easy, you can add this to .tmux.conf

    bind S setw synchronize-panes
Without the on/off option, it acts as a toggle, making it a keystroke away.

I didn't know about it either but found this:


Seems like a neat trick

if you're running it on linux, is any reason to use screen for long-running tasks, instead of Docker?

The reason folks asked, "docker is a screen replacement?" is because one typical use case is using screen within an ssh session where you might get disconnected. screen holds onto the session so that you can ssh back in and continue from where you left off.

    $ ssh hostname
    $ screen
    # some time later, you get disconnected...
    $ ssh hostname
    $ screen -x
    # back to where you were before getting disconnected.

Don't forget mosh exists if you're commonly in situations where a normal ssh session is unreliable: http://mosh.mit.edu

mosh + tmux are simply amazing together. It has radically improved my life, where I keep persistent connections from my laptop to various remote machines.

My only complaint with mosh is how slow it is - my top-level 266x188 tmux session absolutely crawls on it, and it's quite common to see it using more CPU than whatever heavy task is spewing out lots of tty output. Wonderful for the common case, though.

Screen is amazing for SSH work or if you just don't want to have 50 tabs open. I've been looking into tmux lately though for the later. I just found out about it last week.

Seriously, the amount of commands linux has that most people don't know about is staggering. This link[1] was on HN just the other day.

[1] http://www.danielmiessler.com/blog/collection-of-less-common...

I use tmux at work to manage at times up to several dozen sessions each with several windows/panes (I make one session for every conceptual task that I take on, and sessions live until I complete the task). In my experience it is much more robust than screen (not as many dungeon collapses, if you know what I mean) and well worth switching to.

Docker and screen do completely different things, unless you mean some other Docker than what google found for me.

Docker runs a whole container (with embedded OS), screen justs keeps a terminal accessible after a disconnect. I don't see how using Docker fits that usecase.

Docker can be used as a screen replacement?

I'm a heavy Docker user.

I'm using screen right now to scp 4.5Gb from home to my Docker host. I'll close the terminal at some point and check progress tomorrow.

I guess you could do that in Docker.. but why would you?

I haven't explored Docker yet. Some of my team members have been looking into it. Hoping to read up and experiment with it a bit once I have some free time.

I also use byobu but byobu uses preconfigured screen or tmux configuration. You can choose the tmux or screen backend with the commands byobu-tmux or byobu-screen.

Byobu is a pre-configured 'easy mode' for either Screen or Tmux.

I use it all the time on my RasPi at work, running a mutt instance. I can hop in from any machine and have my 'native' email client accessible.

tmux is very scriptable. I have a shell script "go". go <box> opens new tux window splits it twice (3 total panes) all ssh'd into box, one as root, one tailing log files. The "go" script has grown over time, running custom log tails on specific boxes. And one command "vroom" which ssh's into web and db boxes running atop, apachetop, pg_activity in a bunch of panes.

It's just an example. Tux lets you automate interactive shells.

I'd love to see that script. I'm a long time screen user and would love to find a few examples that'll show off what tmux makes easy.

I have switched from screen to tmux and tmux IMHO more convenient (I have about 30 windows in 2..3 tmux sessions). Can't say anything about byobu.

Awesome little program. It's saved so much time so far. For anyone that wants to get up and running:


That contains two tmux config files that add a few things like CTRL+B thenSHIFT+P for a nice layout and a shortcut for switching between panes with ALT+Arrow keys

i use ctrl-up / ctrl-down

    bind-key -n C-up next
    bind-key -n C-down prev
ctrl-left and alt-left/right interfere with too many other cli apps.


Thank you! I did not know about the source-file command. I've been writing shell scripts, instead. You have just changed my entire work-flow!

I personally use:

bind-key -n M-1 select-window -t 1

bind-key -n M-2 select-window -t 2

bind-key -n M-3 select-window -t 3

(...) For an IMHO even more convinient ALT+Number to switch directly to the tab in question, just like in firefox.

That's very similar to CTRL+B then Q then Number. But I have about 5+ panes so I found using the arrow keys a lot easier

Here are my tmux bindings which I have been using daily for over a year. These are configured in iTerm in the Profiles->Keys section using Send Hex Codes.

  Cmd-shift-c: New window
  Cmd-shift-l: New pane to the right
  Cmd-shift-h: New pane to the left
  Cmd-shift-k: New pane above
  Cmd-shift-j: New pane below
  Cmd-l: Focus pane on right
  Cmd-h: Focus pane on left
  Cmd-k: Focus pane above
  Cmd-j: Focus pane below
  Cmd-1: Select first window
  Cmd-2: Select second window
  Option-h: Previous window
  Option-l: Next window
  Command-/: Enter copy mode
I have the same bindings in MacVim. The nice thing about using command is that it doesn't interfere with other cli apps like ctrl.

The following allows you to yank the tmux clipboard into the system clipboard: https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard

Here's a good blog post describing how to use the "Send Hex Codes" for integrating tmux and iTerm: http://tangledhelix.com/blog/2012/04/28/iterm2-keymaps-for-t...

Moving to Emacs, I'm going to miss tmux more than I'll miss vim (there's evil-mode).

I use emacs inside tmux all the time (on a Mac, in iTerm2). Works great.

I find that if I run emacsclient and emacs server, I don't need to use tmux. If I get disconnected, I just reconnect and run emacsclient again. All my buffer states are preserved.

Yeah, as an emacs user, every time a tmux post pops up on HN, I go read about it and wonder what it would really do for me. I guess what I'm seeing is that for my emacs sessions it really doesn't buy me anything. I'd be curious to hear about things I can do with tmux that I can't do with emacsclient and emacs daemon.

Tmux is for your shell sessions. Emacsclient is orthogonal. Or do you do all your shell work in emacs?

> do you do all your shell work in emacs?

I do! eshell is a very good shell that integrates nicely with emacs. For instance, I love egrep in eshell, you can move your cursor over the output and emacs will take you right to the line that matches.

So let me temper that just a wee bit, I do use eshell a lot, but there are a few cases where it doesn't work quite well, but those cases are few and far between, certainly not enough to warrant using tmux, at least I can't be convinced yet.

EDIT: I said eshell integrates nicely with emacs. That's not true, it's a shell written in elisp for emacs, no integration whatsoever. Sorry, but I don't feel like rewording what I wrote, so just adding this edit comment ;)

If you do any sort of work on Middling-to-Fairly-Big Data, eshell is not for you. I love emacs, and would love to love eshell, but I prefer running grep/awk/sed/etc in tmux since it's just soo much faster.

And of course, if you need to use any sort of curses type thing, eshell (or M-x shell) often fails in ugly ways.

I upvoted you because I think you present a fair point, especially about "big data" and curses programs, though I recently noticed that top is behaving well in emacs and I don't think it was before, so maybe it's getting better and I need to revisit some of my old workflows to see if I can incorporate them.

As for running grep/awk/sed in tmux being fast, I don't doubt running the individual program and getting your results is faster, but the interaction in eshell and going beyond, say, grep output and actually being able to go the the line in question, the whole workflow, is much faster than running grep and then firing up an editor on the file and moving to the line. That is the real power, the whole workflow is made faster such that the fact that grep is a slow elisp implementation doesn't matter. And elisp grep really isn't that slow, accessing the file system is the slow part and that's true for both implementations and both can benefit from aggressive file caching anyway.

The less I have to leave emacs during an editing session, the faster/more productive I'll be. And that's the real power of eshell IMO.

As an emacs user I do agree with what you're saying. I do all my codebase searching using ag from emacs[1] instead of grep and I absolutely love it: you get the results in a compilation-mode buffer which instantly jumps you to the search hits.

Maybe I should use eshell or one of the comint shells more. But I wouldn't want to leave bash/zsh behind -- I might as well be on windows then :) (which is, btw, a strong argument in favor of the workflow you're describing -- for those poor people who are forced to use windows, eshell is a blessing.)

[1] https://github.com/Wilfred/ag.el

Thanks for sharing about ag, I'm going to check that out! Luckily I'm on Linux for most of my development, but sometimes I am on Windows and you're right, eshell is a blessing there :)

> And elisp grep really isn't that slow, accessing the file system is the slow part and that's true for both implementations and both can benefit from aggressive file caching anyway.

Sorry, I never meant elisp grep was slow. I meant _piping_ was slow.

Here's regular bash in tmux:

    $ wc -l fullform_nb.txt 
    1180517 fullform_nb.txt
    $ time sort fullform_nn.txt |grep åbryug
    114297  åbryug  åbryug  adj pos m/f ub eint normert     510     1
    114297  åbryug  åbryug  adj pos nøyt ub eint normert    510     4
    114297  åbryug  åbryugare       adj komp normert        510     5
    114297  åbryug  åbryugast       adj sup ub normert      510     6
    114297  åbryug  åbryugaste      adj sup bu normert      510     7
    114297  åbryug  åbryuge adj pos bu eint normert 510     3
    114297  åbryug  åbryuge adj pos fl normert      510     2
    real    0m2.888s
    user    0m9.570s
    sys     0m0.132s

    $ time sort fullform_nn.txt | grep åbryug
    114297	åbryug	åbryug	adj pos m/f ub eint normert	510	1
    114297	åbryug	åbryug	adj pos nøyt ub eint normert	510	4
    114297	åbryug	åbryugare	adj komp normert	510	5
    114297	åbryug	åbryugast	adj sup ub normert	510	6
    114297	åbryug	åbryugaste	adj sup bu normert	510	7
    114297	åbryug	åbryuge	adj pos bu eint normert	510	3
    114297	åbryug	åbryuge	adj pos fl normert	510	2
    111.725 secs
Note: the output from grep comes after about 20 seconds, then it runs for 90 sec's until time is done. In any case, way slower than bash in tmux (which is as fast as bash outside tmux). (Silly example, but my real oneliners tend to be rather longer and more cryptic …)

And when I try to e.g. "sort -k2,2 -t$'\t' file" it gives zero results, doesn't even tell me whether $'\t' is unsupported, same deal if I try '\t', whereas in bash, if I try a plain '\t', sort at least tells me sort: multi-character tab ‘\\t’. In eshell, I might be mislead to thinking the grep gave zero results. To me, eshell is both slow and dangerous.

I'm happy eshell works for you, but it is just not usable at all for me. OTOH, I'm faster at typing alt-TAB than at C-x b esh RET, so I don't mind having to leave emacs as long as I only ever have to switch between the terminal and emacs.

How did you configure the Command key as Meta? I could never get it to work.

Preferences -> Keys, see the heading 'Remap Modifier Keys'.

You can remap left command to left option, leaving right command as command so you can still cmd+tab out of iTerm. You might also have to to to Preferences -> Profiles -> Keys and on the bottom say that the left and right option keys both act as +Esc.

If there's a better way I'd be interested to hear it, but this works for me.

Why? As far as I can tell, Emacs, when talking to an X server or otherwise drawing its own windows (i.e., not in a terminal), is a strict superset of tmux.

what? You can't run emacs in a tmux session?

You definitely can--I do this all the time.

I do literally mean all the time. My current session has been running the same emacs process inside a tmux window for about 60 days now I think.

The tmux project is part of the ones developed alongside and included in OpenBSD, so when you support OpenBSD, you're also supporting tmux.

Can't wait until this gets incorporated onto Homebrew. Apparently there's already a pull request https://github.com/adnissen/homebrew/commit/2b0e92805b445988...

Here's the working homebrew PR, if you can't wait to use it: https://github.com/Homebrew/homebrew/pull/26884. Should get merged pretty soon.

Does anyone know how to save/ retrieve sessions?

Depending on your meaning:

   $ tmux detach

   $ tmux attach
This will deattach and reattach a tmux session. You can type ``tmux detach`` inside a tmux pane of the session you want to detach. Also the key combo ``Ctrl-b d`` will detach.

If you mean a way to save the workspace configuration, tmuxp, teamocil and tmuxinator are great solutions.

(Note, I wrote tmuxp as a python project a few months ago.)

I use tmuxinator[0] to manage it. [0]: https://github.com/tmuxinator/tmuxinator


The one downside to tmux over screen is that tmux basically requires that all clients connecting to it have the same screen size, and by default it chooses the smallest one. So while you can connect to an existing session, the output might be ugly.

For this reason, I typically simply 'tmux detach;tmux attach"

tmux a -d will attach and also detach all other clients.

Tmuxifier (https://github.com/jimeh/tmuxifier) is a great utility for scripting tmux layouts. Well worth checking out if you have complex layouts you want to be able to recreate.

    tmux new -s session_name
Then to reattach

    tmux attach -t session_name
Read it as "tmux, attach to session_name"

Forget which sessions you have open? List them out!

    tmux ls

Leader-d should detach your session safely. "tmux ls" will list running sessions, and "tmux attach -t session-name" will connect you to session-name.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact