Get Started with Tmux

Agreed, mouse mode plus zoom are two huge productivity boosters. Zoom is crtl-b ctrl-z and makes a console full screen.

Wow! This should be in the first paragraph of the man page. Thanks for this tip

Could you recommend any good articles? I've dabbled and enjoyed it but it never stuck with me.

I think I found the session management / default pane arrangement tricky, and would forget the hotkeys after a week or two of not using it.

For me, just keeping my session active in case of a disconnect is worth it, especially when using SSH on a mobile.

It was a bit annoying -fg -bg -attr into single config lines, I really wish they either supported backward compatibility or at the very least did provided an automated conversion. It was a pretty straight forward operation that could easily be automated.

Fundamentally they do the same thing. TMUX has a nice status bar, it's easier to play around with windows and it's got 256 colours support, as far as I'm aware. But really the difference is in TMUX having a dedicated community while GNU screen is just another GNU utility.

When I made the switch from screen several years back, tmux didn't need a patched version to support vertical splits, which was nice. Other things included better support for scripting, nicer configuration, and better mouse support and scrollback behavior by default.

Screen may have caught up a bit since then, but tmux seems to have a more active community and generally faster pace of development.

I usually choose Tmux over GNU Screen because it seems more intuitive to use IMO, but I still choose Screen for some cases like connecting to serial consoles.

Screen is fantastic. Yet tmux btought us the future.

I used to use the Screen as a terminal multiplexer, but for the last 3 years, I have really only used Tmux. It is not better or worse. It's just different :)

I'm sure tmux is great. But I've never seen the need to change. I'd happily read an article that shows me the benefits of changing.

I started using tmux several years ago because it had better script support than screen did, at that time. I also liked the session/pane/window handling better (customization made a lot more sense to me, as a vim user), it supported some plugins that I really liked, and the ability to sync panes was a cool feature that came in handy sometimes (grepping logs for load-balanced applications), but I honestly rarely used.

But I couldn’t tell you now, without some digging, whether screen supports all these features today, or if it’s perhaps even better than tmux.

Here's my take, most of which is in other comments:

If you like GNU Screen, continue using that, they are very similar tools. I’m a long term user of both, using both for a while, and now only using Tmux exclusively. I need a terminal multiplexer, since I often use my main computer via ssh.

The main advantage of GNU Screen for me was it was slightly more robust, it crashed less for me. While both are pretty stable. I can run both for weeks at a time, and not have any issues. Though, I’ve heard others report the opposite about stability between the two tools.

Tmux has some advantages for me:

   - Tmux is scriptable.  You can run tmux commands to query and set  the state
    of Tmux. It is possible to pipe and process those results. There is some
    thought behind the commands, that make them consistent and orthogonal.
    Screen never really could not do much beyond listing the  available
    sessions.
     - This has made it easy for 3rd party developers to create Tmux plugins, adding some useful features.
  - I think GNU Screen can now do split screens, but I feel it is easier to do
    in Tmux.  Many times I have a monitor with full a window terminal, and Tmux makes
    it easy to split that up into smaller independent terminal panes.

  - GNU Screen development had pretty much stalled for years.  Tmux is being
    actively developed.  Outside developers are welcome to make contributions. 
     - The lead Tmux developer, Nicholas Marriot,  is actively engaged with
       users. He responds to bug reports, helping track down bugs, and
       collaborating with contributors.
     - I believe GNU Screen development has started again, but to me it just
       doesn’t have the same level of engagement from the developers.
     - Tmux has regular releases, compared to Screen
  - Tmux is more current with the latest ANSI/SGR/OSC codes, and has robust
    unicode support.  This hurt me most when I use  a wide terminal (> 256
    columns), and wanted to use the mouse, going past a certain column was
    broken.  There is a new encoding SGR 1006, and it didn’t work with GNU
    Screen, but did with Tmux.   GNU Screen picked this up in 2019, but Tmux
    had it for years before.  There are other codes for 24bit color, italics,
    fancy underlines, etc that GNU Screen doesn’t support, but many modern
    terminal emulators do.  Even ITerm2 has Tmux support builtin. While I
    generally don’t need these but if/when I do, Tmux just works, while GNU
    Screen just ignores these codes.

While both are capable and usable, there are a lot of details that make Tmux better to me.

> Or is there a better tool for this?

You can write very simple scripts that perform the actions that you describe. It does not seem that there's a better tool than the shell, for this.

You might find tmuxinator (https://github.com/tmuxinator/tmuxinator) helpful. It doesn't do everything you describe, but I use it to spin up sessions configured per project.

tmuxinator

https://github.com/tmuxinator/tmuxinator

There are other solutions but I used this one for a while and liked it. Then stopped doing as much development at home (work is Windows) and haven't used it in a while. It's easy(ish) to create different configs for different needs. I basically had a Common Lisp IDE or a C++ IDE or whatever set of things I commonly used.

Look into tmux-resurrect[0]. It allows you to save and restore tmux sessions, and an accept-list of running processes within those sessions. Ideally, you'd get the tmux session into the state you want re: windows, CWDs, running processes, etc., save it, and then restore from that session in the future.

[0] https://github.com/tmux-plugins/tmux-resurrect

There are tons of examples on how to do this in the shell. Here is some inspiration: https://stackoverflow.com/questions/54954177/how-to-write-a-...

Very similar to tmuxinator, but in python:

https://github.com/tmux-python/tmuxp

I use this one as I found it easier to set up, and a bit more intuitive to script. Also if you use python rather than ruby, it's easier to understand!

Try the defaults until you get the basics. Look at the help file what you can do and what you need. After that you may want to implement seamless navigation between tmux panes and vim splits[0]. It really isn't a must but hey, it is very convenient for starters since they don't have any muscle memory for switching different splits.

After that maybe try to do same with AwesomeWM and that would be the ultimate navigation setup.

[0] https://github.com/christoomey/vim-tmux-navigator

Try this in your tmux.conf:

    bind -T root M-h select-pane -L

(I’m typing this from my phone from memory, so bear with me if there are minor mistakes.)

The -T root does what you want, ie bind a key without a prefix. M-h is Alt-h, so change that to whatever you want of course.

I am a heavy Vim and tmux user, so if you’d like you can use my own config for inspiration:

https://git.sr.ht/~gpanders/dotfiles/tree/master/item/.confi...

I once added it to my bashrc or as the starting command of my terminal,but I quickly removed it since when configured so, if the session detached you have no easy way to open a non tmux terminal session to use for reattaching.

> are people just resetting its state everytime they leave the remote terminal?

This is literally the reason that people use it. It can disconnect and reconnect to the same session. I have had a tmux session running remotely for over a year and I reconnect with it ever day with all my panes and windows still the way I left them.

I tried this once or twice but didn't understand what it was really accomplishing compared to just starting tmux normally. Mind me asking you to explain how you use it a little bit?

Wow, learned something new today. Very cool.

I use iTerm integration over Eternal Terminal to my workstation all day. It’s great.

And if iTerm2 is a game changer for you, consider that it's written and maintained by one guy. Throw him a couple bucks!

https://www.patreon.com/gnachman/membership

I use Sway and Tmux.

Scrollback, selection, search, and buffer piping are 10x more powerful than any terminal emulator's builtin selection/search/URL-detection that I've tried. With one keybind, I can interactively select Web URLs with the keyboard; with another, I can fuzzy-search both Web and non-Web URIs (including mailtos, gemini://, etc) with FZF. I can use a non-URL regex as well if I want.

I can also detach/reattach sessions, which is useful both with and without ssh.

You get all these features in any terminal emulator you use, including the virtual console (which doesn't normally even have scrollback).

If you build Tmux as a static binary, your favorite terminal emulator is just an rsync command away on any machine you use (assuming you're allowed to chmod +x a file).

No.

Whenever I use a tiling wm, I don't use tmux. Otherwise, I do.

As another user hinted, the difference is mainly about what's your top layer. If it is X11 or Wayland as you would on your desktop/laptop computer, than your tilling wm is the better place for that. If your top layer is a console session, as you would on a remote machine or a local VM, then Tmux is a godsend.

I'll sometimes use tmux as the backend for something like byobu (detaching and attaching to sessions mostly), but that's not really applicable to most local machine workflows.

Everybody I've talked to who uses tmux has switched away from the default keybindings. I agree on straying away from defaults for most things since using custom configs makes it more difficult to work on random servers down the line. But.. tmux is an exception to that rule, especially since it only needs to be configured on one host, and none of the servers you might need to ssh into.

Spend a couple hours some night editing someone else's public tmux config and it'll really pay off.

(FWIW, my capslock has been rebound to be ctrl, and I do ctrl-a as my tmux-mode key. Really recommend if you use a terminal a lot.)

It's just a different philosophy. Ctrl-b turns on tmux mode. The only tricky ones to remember are " to create a horizontal split and % to create a vertical one, but you can remember them based on where these keys split your keyboard (& splits the keyboard down the middle as if you make a verticle split in tmux, " rests along the middle row of the keyboard like a horizontal split). Arrow keys to move about the panes is pretty intuitive. The rest of the commands are easy enough to remember: c to create a new window, n to go to the next window, p to go to the previous window, x to close a pane, & to close the window and all panes.

That's about all you need to keep in your head to get a lot of power out of tmux.

If you struggle with keybindings, you should try _byobu_, it has much saner key setup and shorter learning curve.

Personally I think the default keybindings make a lot more sense then the ones from screen. Specially jumping to the start of the line, in screen, Ctrl-a a ... common ;P

As with all software, if you are used to the setup of an alternative program, it takes time to retrain your musclememory.

IIRC, tmux was originally developed inside of screen, so ctrl+b was chosen so it wouldn't conflict with ctrl+a

I used Terminator for a while and loved it, but eventually succumbed(*) to tmux. With tmux I get consistency across both local and remote connections. My remote connections have tiled shells and save state when my VPN goes down.

(*) - I still use Terminator, but only to provide tabs(tabless tabs in a fullscreen window with no borders) that I can easily switch between(Alt-#). I guess now that I'm comfortable with tmux I can probably drop Terminator entirely.

Or even terminal clients with split panes such as iterm. You can even configure it to autoconnect to remote servers on a per profile basis.

I like having the familiar emacs keybindings to navigate the terminal, e.g. to be able to scroll quickly, search, and copy/paste without needing to take my hands off the keyboard.

I'm sure there's some terminal emulator that supports that...any recommendations/suggestions/configs?

I think so, and my evidence for that is I've been using tmux a lot less as I've done more of my development work locally.

BUT - it still has plenty of utility when working on remote machines. So, I still use it every day. I'm just not constantly working in it.

I've used tmux within a tiling wm for years. I never really understood this view that you don't need both, but it is common. I don't want a bunch of separate terminal windows. I lay out my tiles around having one main one, and then from there I split into tmux panes and windows. It feels neat and dense this way. I have a keybind to jump to my named terminal with tmux. It's easy to open a new tmux window with a few keypresses. It's easy to work with the scrollback. The layout stays consistent.

I feel naked without tmux. I naturally want to do various tmux actions. It's maybe like pinned vs unpinned browser tabs. If I have a terminal without tmux running, it feels like I'll close it soon, so I don't get attached, and it bugs me a bit the longer it's open.

I still use split windows inside vim and emacs as well. Some say it's silly or redundant, but they all work a bit differently and have their own functions. Emacs can scroll the "other window", vim has an extra clipboard.

You can write scripts to automatically open up tmux windows to certain directories/files/software arranged and named however you like. it can be handy to open an entire development workspace for a project with a single command. I'm not sure if other tools like i3 can do this.

Memory usage? 20 terminal emulators will consume half GB of memory.