
Benefits of using tmux – streamlining your development environment - gkze
https://blog.bugsnag.com/benefits-of-using-tmux/
======
mambodog
If you want to get a taste of the benefits of tmux without having to learn
anything new, I recommend using iTerm and setting up an alias for

    
    
      'ssh [your server] -t "tmux -CC attach || tmux -CC"'
    

Just running that command will connect to your server and attach to an
existing tmux session, or create a new one if needed, and make use of iTerm's
tmux integration, so you can use the standard macOS keyboard commands (or the
UI) to do things like switch tabs, make new tabs, close them, make new
windows, etc. all using tmux and a single ssh connection. You can press 'esc'
in the command window to detach from your session and when you return (just
using that alias) all your work is just as you left it.

~~~
blfr
Use mosh[1] instead of ssh for superior handling of weaker connections and
roaming. You close your laptop one place, go elsewhere, switch to LTE,
whatever, open the lid and you're back on. Don't even need to reconnect.

[1] [https://mosh.org/](https://mosh.org/)

~~~
ue_
It's a real shame that it can't handle X11 forwarding, which is pretty much
all I use ssh for nowadays.

~~~
tlavoie
Well, that and tunnelling all sorts of other traffic, basically mini-VPN. I
use this all the time for a variety of remote systems (or local, _I_ am the
remote one).

------
minhajuddin
I use a tool called tummy
([https://github.com/minhajuddin/tummy](https://github.com/minhajuddin/tummy)
full disclosure: built by me) which allows me to create a Tmuxfile per
project. A typical file looks like this:

    
    
      session "liveform"
      directory "/home/minhajuddin/r/liveform/frontend"
    
      window "src", [
        pane("vim TODO"),
      ]
    
      window "server-pry", [
        pane("puma --port 3000 --config <(echo '')"),
        pane("rails c", :horizontal),
      ]
    
      window "play", [
        pane("git status"),
      ]
    
      window "misc", [
        pane("sidekiq"),
        #pane("httpdebug", :horizontal),
        pane("cd ~/s/html; fs", :horizontal),
        pane("guard", :horizontal),
      ]
    
      # vim: filetype=ruby

~~~
positr0n
I used to use tools like that (tummy, teamocil, etc) but I've since discovered
tmux-resurrect. It persists tmux sessions, windows, panes, and a whitelist of
non-destructive commands like vim and top across reboots. Now my tmux sessions
just organically grow and shrink as necessary and I never worry about having
to recreate them.

Of course I can see the case for combining both tools. If you have a lot of
projects, and/or want REPLs loaded you might not want them sitting around in
memory for months if you're not going to use them.

It is trivial to get working. Just use tmux plugin manager to install tmux-
resurrect and tmux-continuum.

[https://github.com/tmux-plugins/tpm](https://github.com/tmux-plugins/tpm)

Example usage in my dotfiles:
[https://github.com/positron/dotfiles/blob/master/.tmux.conf#...](https://github.com/positron/dotfiles/blob/master/.tmux.conf#L72-L99)

~~~
nnutter
Does it save environment variables too?

~~~
minhajuddin
It doesn't save anything, it is just a startup script to get your tmux session
set up the way you want. You can however, have env vars in the script or
source from a particular file. e.g.

    
    
      session "grnc_hub"
      directory "/home/minhajuddin/a/grnc_hub"
    
      window "server", [
        pane("RAILS_ENV=production rails s"),
        pane("source ./.env && rails s"),
      ]
      ...

------
Touche
To me tmux, like a lot of tools, suffers from bad defaults that makes it less
enjoyable to use. One example is not being able to scroll with a mouse. I
usually find someone's tmux.conf online and use it, but always run into
strange problems that I don't have the energy figuring out. My current conf
suffers from the navigation bar going completely black when I try to rename a
pane (can't see what i'm typing).

Really wish more tools took care into making solid defaults and not assuming
all users are like the ones on their mailing lists.

~~~
girzel
I was able to work out pasting into tmux from the system buffer, but no
solutions I've seen for copying _out_ of tmux have ever worked for me. So yes,
that's a pretty basic usability issue.

~~~
rhinoceraptor
I have a plugin I use for that [1]. I enter copy mode, either by scrolling
with the mouse or hitting Prefix + esc. I have the copy mode key bindings set
up in vi mode (as is my shell), so I navigate around, hit V to enter visual
mode, select some text and hit y. Now that text is in the system clipboard.

[https://github.com/tmux-plugins/tmux-yank](https://github.com/tmux-
plugins/tmux-yank)

------
simosx
I use Byobu ([http://byobu.co/](http://byobu.co/)), which is a configuration
layer over tmux. It's tmux with nicely packaged features.

~~~
dleslie
As a screen user, Byobu is the best alternative. When I muscle-memoried screen
commands the first time Byobu detected my actions and asked if my
configuration ought to be changed to use screen bindings. Now that is UX done
right.

~~~
hughw
Yes -- same for ctrl-a, its normal escape sequence. It detects emacs users
typing ctrl-a and invites you to map it the way you want.

------
patrickdavey
If you use tmux and vim, and if you run tests, then you must look at
janko-m/vim-test and vim-dispatch. Runs any test seamlessly in the background.

Vim-dispatch also has the best intro video to anything ever ;)

[https://vimeo.com/63116209](https://vimeo.com/63116209)

~~~
anonymousDan
Video is awesome. What is the advantage over just having a separate
tmux/screen session in which you launch your command though?

~~~
patrickdavey
Well, the nice thing here is that with the integration between vim-test and
vim-dispatch is that you don't have to do anything for having the tests run in
a separate session. It just works. I mean really you _are_ just having it run
in a separate session, just more smoothly.

If the tests pass then the tmux window the tests were run in will just
disappear, if not, you get popped back to the quickfix window with the errors
listed.

Give it a go and see how you like it! :)

------
chriswarbo
I'll give a shout-out to DVTM ( [http://www.brain-
dump.org/projects/dvtm](http://www.brain-dump.org/projects/dvtm) ) which I've
been using successfully for a couple of years.

Prior to that I used tmux for a few years, and screen before that. I suppose
the only compelling reason to use DVTM is that it acts like a tiling WM, so if
you use one (I use XMonad [http://xmonad.org](http://xmonad.org) ) the
experience is basically the same (mod-h/mod-l to resize, mod-j/mod-k to
navigate windows, mod-space to switch layout, etc.).

The main reason I switched is my preference to avoid bloat. DVTM doesn't do
everything tmux and screen do, it _only_ does window management. I use dtach (
[http://dtach.sourceforge.net](http://dtach.sourceforge.net) ) for
persistence. I previously used abduco ( [http://www.brain-
dump.org/projects/abduco](http://www.brain-dump.org/projects/abduco) ), but it
segfaulted on me a couple of times (months apart, in a non-reproducible way);
haven't tried it for about a year, so it might have stabilised.

I use st ( [http://st.suckless.org](http://st.suckless.org) ) as my terminal,
again to avoid bloat.

~~~
cm3
I cannot use st because it still has corner cases that xterm works well but st
doesn't yet, and I find the need to patch the sources hard to maintain when a
new release comes out and has refactorings included.

But I must say that st's font rendering of Unicode is more complete than rxvt-
unicode or xterm. With the same font configured in all three, st is the one
that manages to render the most glyphs of plan9port's unicode sample file.
Would be great to have the same in urxvt or xterm.

------
mrbill
I've used screen for darn near 20 years now. Have tried to switch to tmux, but
even with screen-like keybindings, I end up running into something[0] that
makes me switch back because screen is just muscle memory for me at this
point.

[0] like switching to a non-existent-numbered screen to get a list of which
ones I _do_ have...

~~~
jlgaddis
I was the same way when I first started using tmux. I just "fixed" the
keybindings in tmux to what I was used to and went about my business.

It is slightly inconvenient the first time I fire up tmux (with the defaults)
on a new host. I just take a 30 second break, create my customized
~/.tmux.conf, and continue on like nothing happened.

------
nextos
Does anyone run tmux with a tiling window manager for local development?

If so, what are the advantages? I know automating sessions is one of them, as
explained in the article.

I am more interested in hearing about interactions with the terminal. You
already get good mouse-less window management with something like i3 or
xmonad.

How about copy & paste? I use urxvt plugin for this, but I often find myself
using the mouse to select and middle-click. Is tmux better?

~~~
devereaux
I do that, not in a real "tiling window manager" but something very close:
openbox, set to show no titlebars, and using shortcuts to title the windows to
precise positions. I have 3 position: most of my screen on the left, a small
vertical slice on the right, a smaller chunk underneath. If I want a titlebar
for some application, I have a shortcut that will give the window a titlebar,
and then I can move it around with the mouse if I want to. So I get the best
of both worlds.

Surprise - I don't run tmux. It is simpler to have several roxterm, in these
position, with various tabs open. When I work remotely, I use screen on the
remote host, but that's all.

To give you an idea of my shortcuts, in a real life scenario ; my caps lock is
remapped to control or escape with xcape:

\- esc: pop a new roxterm and from wherever I am, bring me to the terminal
desktop

\- f9: resize this roxterm to the left part of the screen

\- esc: pop another roxterm, focus it

\- ctrl-f9: resize it to the right vertical slice of the screen

\- f4: switch to the browser desktop

\- f12: put by browser in full screen, to check some reference without
distraction

\- f5: switch back to the terminals desktop

\- alt-tab: switch to the roxterm that's currently on the right

\- f12: make this roxterm full screen to do something without distraction for
a while

\- f12: demaximize and put back this roxterm where it was

\- f9: now move this roxterm to the left, over the other one

\- alt-tab: move to the other roxterm that was on the left

\- ctrl-f9: put this roxterm in the vertical slice position on the right

\- ctrl-space: make this roxterm sticky, showing on all desktop

\- f4: move back to the internet desktop to check more documentation

\- f9: resize the browser to be on the left part of the screen, so that I can
see both the browser and the roxterm

\- f5: move back to the terminal desktop. The space occupied by the browser
will be replaced by the roxterm I left there, on the left

\- alt-tab: move focus to this roxterm

\- ctrl-t: open a new tab in this roxterm

\- ctrl-v : paste some stuff from the internet browser

(etc..)

I have accomplished all that with about 20 keystrokes, from muscle memory.
When I connect my extra wide screen, f10 and f11 have similar windows resizing
function as f9 do on the laptop screen. f1 to f8 take me to desktop dedicated
to some use or another (f7 is the windows desktop, with visual studio, f6 is
the rstudio desktop, etc)

One think I positively hated until recently: copy and paste. Muscle memory
means ctrl-shift-c in one application and ctrl-c in another didn't work. So in
the terminal, I remapped the sigint signals to ctrl-x with stty. Hitting
ctrl-x is just as convenient as ctrl-c and now I can copy paste as needed.
ctrl-v to enter verbatim sequences is done with ctrl-q, just like in vim. so
ctrl-c and ctrl-v work everywhere.

When I catch myself wanting to use the x copy paste buffer, the middle click
is not so hard: on a thinkpad keyboard, it is right below the space key. But I
just prefer ctrl-v. The luxury of having 2 independant copy-paste buffers is
appreciable for some tasks however :)

Anyway, sorry for the long reply. I just don't have a lot of opportunities to
talk about my setup. I am some kind of an optimization freak, I know it. But I
don't want an interface to bother me. I have been using that for the last 3 or
4 years after giving up on OSX, and it has one great quality: I don't have to
think about it. It just work the way I want. YMMV of course.

~~~
nextos
Thanks, this is very interesting.

I agree one of the major pain points of X11 systems, terminals, etc is the
clipboard. So many different concepts and shortcuts across programs.

I use xmonad, urxvt or xterm, emacs-nox and vimperator. I'm trying to make all
them consistent. Perhaps the last thing to polish in my setup.

~~~
ramblenode
Not ideal, but the best solution I've found so far for moving text between the
command line and other applications in urxvt is setting Bash to vi mode and
then using visual mode for yanking/putting. I have Vim as my $EDITOR, which is
opened when entering visual mode (I believe opening the editor is default Bash
behavior). Vim is set to use the system clipboard ("set clipboard=unnamedplus"
in the .vimrc) so from there I can bus text to/from other applications.

Dealing with stdout/err is another beast...

------
du_bing
I recommend the book: Tmux--Productive Mouse-Free Developmenet, written by
Brian P. Hogan. It's a concise and practical book about Tmux. There are some
usable configuration in it, and you can learn something about concepts like
session, window, pane in the book. After you combine vim style with tmux, it's
quite perfect to do anything in the terminal. Haha, enjoy!

------
_vya7
This is actually why I prefer Emacs. I can literally do all my development
work in Emacs, with a full-featured shell (e-shell), directory explorer (dir-
ed), REPL and full IDE for Clojure (CIDER). It's pretty great.

~~~
elwell
> a full-featured shell (e-shell)

My experience wasn't so simple. Griefs: coloring, git support problems, bash
aliases. I'm sure there's a way to get it to work, but I wouldn't call it a
full featured shell out-of-the-box; at least, it doesn't really compare with
Terminal.

~~~
sdegutis
For git I use Magit, I don't have any bash aliases, and anything I would
normally see coloring in when using bash in a real terminal has a full-fledged
Emacs analog.

------
joatmon-snoo
When I was first introduced to tmux, I was _really_ excited by having a
terminal session I could reattach to. I was never able to get very deep into
it though: (1) a lot of the time a single script would get me up to speed, (2)
the extra layer of abstraction broke some stuff I was doing, and (3) I
couldn't make heads or tails of a lot of the tmux documentation. I'll
definitely take a second look at a lot of the things people are posting here,
but in the meantime, is there somewhere I can actually learn how to use tmux
properly?

~~~
estreeper
Half a dozen commands will get you 90% of the way there. After you've run
tmux:

    
    
      ctrl+b followed by...
      % - split pane vertically
      " - split pane horizontally
      arrow keys - change pane you're typing in
      :new-window
      2 - switch to window 2
      x - kill pane
      d - detach
    

Command line arguments:

    
    
      tmux list-sessions
      tmux attach #will attach to last session by default
      tmux attach -t0 #will attach to session 0

~~~
mickael-kerjean
A nice and convenient shortcut for:

tmux list-sessions

tmux ls

------
susam
One of the first things I had to with tmux is figure out a convenient prefix
key. I found the default prefix key (C-b) to be a little clumsy to use. After
a little experimentation, C-j has become my secondary tmux prefix key of
choice.

It doesn't interfere with my shell or Vim usage. C-j is redundant in shell as
well as Vim because it does what pressing the Enter key would do. Further, in
Vim, C-j is synonymous to j in normal and visual modes. C-j is also very easy
to type because my right forefinger always returns to j while resting.

This is what my ~/.tmux.conf looks like.

    
    
      # Set C-j as secondary prefix key.
      # C-b remains intact as primary prefix key.
      set -g prefix2 C-j
      bind-key C-j send-prefix -2
    
      # Eliminate delay after <Esc> key press in Vim.
      set -g escape-time 0
    
      # Let Vim use 256 colors.
      set -g default-terminal screen-256color

~~~
ams6110
I use C-], but basically pick anything that isn't a common bash or emacs
cursor movement. I can't use C-b as that is my "backspace"

------
mcescalante
I've been using tmux heavily in my local development workflow for the last 6
months or so, and it absolutely pays off to have three window tiles in a
single terminal window at a bare minimum. I am also using teamocil to manage
windows and panes in tmux, although it's not needed at all:
[https://github.com/remiprev/teamocil](https://github.com/remiprev/teamocil)

When I set up initially on OSX, the conf took me a few to get right so that I
have some mousing abilities and reasonable vim support. Here is a copy of my
(simple) tmux.conf file:
[https://gist.github.com/mcescalante/004e649d8484574ce9d296ad...](https://gist.github.com/mcescalante/004e649d8484574ce9d296ad69a80a08)

~~~
joshuakarjala
How do you get into VI copy mode?

~~~
mcescalante
Either (v) for visual and the arrow keys, or (V) to select entire current
line, then (y) to yank. (yy) will also yank lines without entering visual
mode, which I use a lot.

If you're asking how I copy in general from stdout with the cursor, I select
the text (selection appears yellow) and press Enter and it copies to the
clipboard :)

------
AceJohnny2
_" All problems in computer science can be solved by another level of
indirection"_ David J. Wheeler

Tmux/Screen provides an extra redirectable abstraction layer over the terminal
device.

The biggest complaint I regularly see about it is that people are used to the
screen keybindings. I wonder why not add an abstraction layer there, where
keypresses really call commands that perform the actions, and you could
reconfigure these.

This is how Emacs has done it for 30 years...

~~~
snerbles
> The biggest complaint I regularly see about it is that people are used to
> the screen keybindings.

That's my problem with Tmux. Ctrl-a,d is already burned into muscle memory,
and for my applications Screen is "good enough".

~~~
jitl
Tmux expects you to rebind its leader to Ctrl-a once you're ready to move off
of screen. Otherwise, it's default works nicely if you are nesting screen
inside of Tmux or vis-versa

~~~
AceJohnny2
I use Ctrl-a as the "go back to beginning of line" shortcut that Readline-
capable programs offer by default [1]. That's actually one reason I never got
used to Screen ;)

[1] that is, using the Emacs keybindings it exposes by default. I know you can
change that through .inputrc

~~~
jyriand
I'm using Ctrl-a on tmux, and to get back to beginning on line I just have to
press it twice Ctrl-a Ctrl-a.

------
baby
I use Tmux resurrect[1] with Tmux continuum[2] so that after rebooting my
laptop, my tmux session is restored.

[1]: [https://github.com/tmux-plugins/tmux-resurrect](https://github.com/tmux-
plugins/tmux-resurrect) [2]: [https://github.com/tmux-plugins/tmux-
continuum](https://github.com/tmux-plugins/tmux-continuum)

~~~
garou
If you use ViM, vim-obsession[1] work with tmux-ressurect[2] to restore vim -S

[1]: [https://github.com/tpope/vim-obsession](https://github.com/tpope/vim-
obsession) [2]: [https://github.com/tmux-plugins/tmux-
resurrect/blob/master/d...](https://github.com/tmux-plugins/tmux-
resurrect/blob/master/docs/restoring_vim_and_neovim_sessions.md)

------
partycoder
iTerm2 has integration with tmux. Much better than the default Terminal
shipped with macOS.

~~~
microcolonel
I greatly prefer Terminal.app on OS X, very standards compliant and
predictable; if a bit slow but iTerm2 is slow as well.

~~~
sethhochberg
iTerm's killer feature for me is the special paste modes - it is trivially
easy to do things like visually select a block of processes numbers from ps
and then paste that block as a space-delimited list on one line to kill them,
etc. Terminal.app is fine for most things but can't do stuff like this.

~~~
mi100hael

        ps aux | grep 'thing' | grep -v grep | awk '{print $2}' | xargs kill

~~~
amyjess
My own version of that command:

    
    
        ps -ef | grep 'thing' | awk '{print "kill -9 " $2}' | sh
    

On most of my systems, I tend to make a shell script out of it and usually
save it to /usr/local/bin/kll (and I don't care about grepping out grep
because it doesn't seem to affect anything).

~~~
partycoder
grrr....

    
    
        pkill thing
    
        killall thing
    

And then there's also pgrep instead of ps | grep

~~~
amyjess
killall and pkill don't work if the thing I'm trying to grep for isn't the
first word of the process string.

Let's say I'm trying to kill 'python foobar.py' but I don't want to kill
'python bazquux.py'. The only thing it'll respond to with killall is 'killall
python', but then both of them will respond. So I have to grep out the
parameter and then kill that, with: ps -ef | grep 'foobar.py' | awk '{print
"kill -9 " $2}' | sh

~~~
skovorodkin
Check out -f parameter of pkill.

~~~
amyjess
Ooh... nice! Thanks!

------
ghshephard
The one issue I have with tmux, versus using iterm natively, is that every
single time I have to reboot my machine for an operating system upgrade, I
lose all the terminal history of my tmux sessions - whereas with iterm, when
the machine restarts, it restarts with the all the windows and terminal
histories intact.

Its ironic that tmux doesn't provide any mechanism to save your terminal
history between reboots. Tools like tmuxinator/tmux-resurrect will save your
session/window/pane configs, but you lose all your history...

If I could just recover my (typically very valuable) terminal history between
reboots, tmux would be the perfect tool for managing my terminal
environments...

~~~
igg
tmux-resurrect seems to have an option to save bash history. When combined
with tmux-continuum, it should happen seamlessly.

~~~
ghshephard
The history I'm referring to is the scrollback buffer. The work that I do,
which is predominantly interactive in a REPL like environment with remote
devices, has a rich history of information in each window/pane. I dread losing
those scrollback buffers every time I have to restart tmux.

------
godmodus
screen master race reporting it!

that said, i do mix screen on the local machine and tmux on the remote
machine. lazy, but does the trick. of course one can script either to do
everything one needs.

------
hansjorg
As an unsophisticated screen user without any interest in what seems to be a
turf war, what is the deal with the never ending stream of "Use tmux!"
articles on here?

------
gitaarik
I came from screen when I started using tmux. I spend quite some time to make
the key bindings similar to screen, however, kept some things the tmux way
because it was better. For people interested, this is my complete tmux.conf:

[https://github.com/gitaarik/tmuxconf/blob/master/.tmux.conf](https://github.com/gitaarik/tmuxconf/blob/master/.tmux.conf)

------
mark_l_watson
I do a lot of work in ssh shells, and somehow years ago I got out of the habit
of using screen or tmux. I just took 20 minutes to go through the tutorial
linked in this article.

With a pane open as a shell and another pane opened with emacs+intero almost
immediately it felt better than using different ssh shells, which is what I
usually do. The control-b prefix character use never interfered with any of my
activities.

------
Samathy
I've been a GNU Screen user for a good while. The increased productivity is
wonderful.

However, I'm prevented from switching to Tmux because you can't attach to the
same session from multiple terminals, and show a different window in each
terminal.

I use this all the time in Screen - in Tmux, changing the window being viewed
in one terminal, changes all other terminals attached to that session.

------
hhsnopek
I dropped tmux for neovim terminal emulator with neovim-remote to hook into my
existing nvim session. So far so go!

~~~
cyphar
How do you deal with :terminal replacing your current buffer (it close it when
you exit the shell). And the fact that as far as I can tell none of your
keybindings work when you're inside :terminal?

~~~
hhsnopek
Here's my terminal mappings:
[https://github.com/hhsnopek/dotfiles/blob/master/.nvimrc#L93](https://github.com/hhsnopek/dotfiles/blob/master/.nvimrc#L93)
Otherwise I use neovim-remote ([https://github.com/mhinz/neovim-
remote](https://github.com/mhinz/neovim-remote)), which will soon be natively
in neovim, but until then you can connect to your vim instance and either
create a new buffer or replace the existing one. You perform your things and
then use `:w | bp` and jump back a buffer if you created a new one.

Similarly my keybindings can be mapped just as I did in my dotfiles (first
link). Probably my favorite part is being able to search my terminal instance
in vim style with `/` and navigate as I would in any other file

------
beefsack
I started writing a terminal multiplexer in Rust, partially because I wanted
to fix clearing ANSI escape codes to EOL, but also because I wanted to try and
come up with a multiplexer that had very similar shortcuts and commands to
Vim.

~~~
Lio
That sounds like an interesting project.

Another approach might be to use NeoVim which now has a built in terminal
emulator. [1]

[1]:
[https://neovim.io/doc/user/nvim_terminal_emulator.html](https://neovim.io/doc/user/nvim_terminal_emulator.html)

------
rcarmo
Hmmm. I had no idea there was powerline for tmux (I used powerline a couple of
times in vim, then lost patience with it because sometimes I'd lose the wedges
for some reason. It was early days then).

------
gaur
Looks like a nice .tmux.conf. Wonder if it's online anywhere.

~~~
Artemis2
From the author's GitHub repository:
[https://github.com/keeganlow/dotfiles/blob/master/.tmux.conf](https://github.com/keeganlow/dotfiles/blob/master/.tmux.conf)

~~~
orbitingpluto
Long time tmux user.

Thanks for posting the .tmux.conf link. Modified the window decorator line as
sometimes you can't always tell which pane you are in:

set-option -g set-titles-string '#(whoami)@#H session: #S window: #I-#W pane:
#P'

Also noticed that the status right only updates the time if you perform a tmux
op.

------
edem
I've never heard of tmux. Where should I look? Little hint?

~~~
derwiki
... first Google hit? [https://tmux.github.io/](https://tmux.github.io/)

~~~
edem
You misunderstood the question. I'm more interested in how a terminal
multiplexer is good for me.

------
jerguismi
The one reason why I would prefer tmux over screen is that it is possible to
script it. AFAIK screen is much more difficult to script.

~~~
ngoldbaum
Screen has awful support for unicode. When people started using emoji a lot on
IRC i swtiched so irssi would stop moji-baking.

------
hendry
As developers we need a super simple way to log a session. Unfortunately
that's non-trivial in tmux.

[https://github.com/tmux/tmux/issues/629#issuecomment-2584153...](https://github.com/tmux/tmux/issues/629#issuecomment-258415386)

------
mmanfrin
Does anyone know the color scheme used in the examples? It is very nice.

------
johncoltrane
Benefits of using tmux if you don't need it: none.

------
draw_down
I prefer opening tabs in my terminal window instead of this or other similar
tools. It's not an exact replacement but I try to avoid learning and
remembering new sets of keystrokes, and there are some other small UI wins in
my opinion.

~~~
Vekz
I agree with you. I like that I can rip off terminal tabs and move them
around. Also move them to different virtual desktops. I tend to have a virtual
desktop for each project I work on keeping things spatially separate that way.
One piece of functionality missing form this setup is the "pre configured
scripted dev environments" but i've used this tool

[https://github.com/achiu/consular](https://github.com/achiu/consular)

to achieve that behavior

------
st3v3r
It's definitely a cool tool if most of your development uses the command line.
As a mobile developer, however, most of my development is spent in IDEs. Alas,
that means my use of tmux is limited.

------
jlebrech
linux/unix as an IDE has it's merits. are there any specific distros that
focus on setting up an environment?

