The one thing I hate about tmux is that it leaks env vars across instances:

    # terminal 1, start a fresh first tmux session, which magically spawns a daemon with the same env
    $ env FOO=bar tmux
    
    # terminal 2, start another tmux session, which reuses the daemon's env
    $ tmux
    $ echo $FOO
    bar

Try the same with `screen` and you're safe.

This is especially annoying when you're using, say, direnv, and project-specific env vars appear magically on an unrelated subsequent session because your first `tmux` turned out to be from a direnv-enabled directory, which polluted the global environment, which in turn pollutes every subsequent session environment as long as a session (not necessarily the original one) is alive.

Replace FOO with SOME_SECRET/ACCESS_KEY/TOKEN and you can actually accidentally expose/leak stuff or point to the wrong thing.

The unattended workaround is to have the tmux daemon spawn at login via `start-server` + enable some tmux settings like `exit-empty` plus some I can't recall regarding environment handling, but nobody does that.

You can start the server as a user session service if you have a service manager for that, like systemd, instead of needing to do it manually. For systemd specifically, tmux also supports socket activation for the server since some time ago, so you can do that to start it on-demand.

> The unattended workaround is to have the tmux daemon spawn at login via `start-server` + enable some tmux settings like `exit-empty` plus some I can't recall regarding environment handling, but nobody does that.

I just have my terminal emulator spin up tmux when it starts, and I start my terminal emulator from my desktop, so it always runs in a clean environment.

> Ctrl+a from my cold dead fingers

That conflicts with the standard Emacs binding to move to the beginning of the current line. Many years ago, I switched to C-z instead, on the theory that it is really easy to type C-z C-z when I really want to suspend whatever is currently running.

Pity that (AFAICT) terminals have no concept of Super and Hyper (USB doesn’t know about Hyper, either, but at least X11 does).

Our finger memory for ^a is now ^a-a. In all apps, everywhere. Mostly that just results in something like select-all+select-all, but occasionally it's awful

> That conflicts with the standard Emacs binding to move to the beginning of the current line

Also in Bash.

> Ctrl+a from my cold dead fingers

As someone who uses `set -o emacs` I cannot possibly imagine pressing C-a C-a to go to the beginning of the line

Also, as an iTerm2 user: the integration with tmux control mode (tmux -CC) is just amazing for the way I use tmux

As someone who also uses emacs, I type C-a a so often that sometimes I do the same in emacs and it leaves an extra a. It's quite rare though.

As a vim user, this was my attitude about ctrl-b ctrl-b for pgup because tmux uses that. But I got used to it. Like many a screen convert to tmux, I used to map to ctrl-a, but I found myself actually getting pinky/wrist pain from using just my left hand. As a non-emacs user, I'm not okay with that :P So ctrl-b forces me to use two hands.

I remap the screen escape key to Shift-Ctrl-^:

  escape ^^^

C-a C-a definitely annoyed me at first, but I got used to it and now I don't mind it at all.

Yeah maddening! But you can remap it. I use this in my .screenrc to make it C-f:

escape ^Ff

C-f moves forward a character which is also useful. The easiest to type character that had the least impact I could find was to remap to C-j. Works well in both Dvorak and Qwerty layouts and that's the one emacs shortcut I use so infrequently that I can live with having to type it twice.

C-Space here

That’s my default as well, worked great, except on a machine with shared sessions, a test driver machine where several of us will login as the same user: some of those people come from windows machines where ctrl-space gets mapped to ctrl-@, which is NUL.

So we had to find another prefix for those machines; fortunately, tmux can have two.

This (space->@->NUL) is mentioned in the tmux docs, tbh.

C-o here. And C-x or C-p on a few rare nested screens in one particular screen session that I always have open. Those are identified by differently colored tabs in the hardstatus bar which is always visible.

C-t for me

I map mine to C^] which I find to be a good balance between easy to type and not conflicting with other tools

This is actually a very handy readline shortcut to search for a character. Useful when editing long command lines. Granted, I use Ctrl-Shift-] more often (searches backwards).

Why did you switch to tmux? It seems to me that screen is more ubiquitous, and has more features. Having a modem is a pretty handy thing built into it.

Not GP, but ~15 years ago tmux offered a lot better screen splitting options and a few other features that screen did not. That's why I switched. I did continue to use screen at work because it was ubiquitous, but then sysads started installing tmux as well and that was no longer an issue.

screen has improved a lot since then, but it lagged behind substantially for years.

Yes, this is exactly why I switched as well.

Also a benefit was actually being able to understand and edit my conf file without having to RTFM everything. Certainly not a reason to switch by itself, but a nice plus.

I was a very long time screen user and tried tmux early on in its existence. It was slow and different so I bailed back to screen. Last year I tried tmux again and have switched to it full time.

One of the things I like most about it is how easy it is to extend. In the role I was in last year, I'd have several long-lasting SSH sessions to various hosts. With a very simple bash script I was able to create a prompt in tmux that I could trigger to ask me where I wanted to ssh to. If I already had a connection to that host, it would switch me to that window, if not, it would create a new one and ssh to the host.

I wanted to do that in screen for years, but it just didn't have the features to facilitate it. On top of that I was able to easily re-map all of the keybindings to be just like screen for my muscle memory.

Ubuntu, and probably other distros, have screen as a hard dependency for doing upgrades to new release versions on the command line (do-release-upgrade command). I encountered it again just the other day while updating to an LTS version. It's a fantastic feature to have by default, in case your ssh connection gets dropped during the upgrade or something.

People say tmux is more powerful. Whatever that means?

Screen seems to cover all my needs and it learning it is easy. I came for the tabs (windows), sessions, copy and paste - but the must have for everyone is the scrollback buffer. You need it! Especially since we can scroll one the plain terminal.

> People say tmux is more powerful. Whatever that means?

I very rarely use screen/tmux nowadays, but as I recall tmux is a better fit for someone who wants to script their interaction. It makes it easy to send keys to other panes/windows in the session, and also to capture the content from other existing panes/windows.

Thanks. I don’t need that features but I see the use case for others.

It doesn't seem like screen has plugin support - while tmux has a fairly large plugin ecosystem.

> Having a modem is a pretty handy thing built into it.

in what way?

when I worked in the embedded software industry long ago, I spent lots and lots of time connecting over serial ports to dev boards, using software like Minicom. Being able to do that in screen itself would be neat. Tmux does it.

Screen does connect to serial ports. Just open the device and append the line parameters you want to run on the port. Unlike modem dialers like Minicom, you don't have to screw around with on-hook off-hook distinctions or an intrusive TUI.

Ha, I have only ever used screen for serial comms and only learned about Minicom from this thread

Exactly the other way around for me! I've been using screen since forever, and had no idea it could do that. Minicom I still know from the dialup dark ages.

When I worked with embedded systems, I used both, and didn't really understand the differences and nuances between them, and now I wish I did.

Connecting to serial devices. You can for example get a USB uart dongle, and then connect cables to some device where you have uart pins. Most recently I was doing something like that for an esp32 board, and used screen.

> Looks like you can set a password on it now, which is cool

I wish they didn't support that. There's not actually a security boundary there since you can't just reattach to another user's session anyway, and a lot of security people make stupid rules like "if something supports a password, you always have to use one".

Truecolor finally being released is big

I'm looking forward to trying this indeed.

I'm wondering if the use of wcwdith() will improve my luck with using UTF-8 characters in my caption and hardstatus lines. I'd like to be using nerdfonts in there but it just makes a mess.

The entire wchar_t API is hopelessly broken. It isn't guaranteed to represent Unicode nor is it guaranteed to be UTF-32. Unicode has a large number of codepoints designated as ambiguous width. This is largely due to existing narrow text presentation symbols being gifted a wide emoji representation. Which width is the default is heavily dependent on the font(s) in use and your rendering engine. Gnome VTE has a configuration option to set the default width for ambiguous codepoints.

Any program has to expect wide, narrow, or an inconsistent mixture of both if font substitutions are invoked. With no actual API to reliably discover a codepoint display width, your best option is to print some candidates and check the cursor position as a heuristic.

FWIW, wchar_t is guaranteed to be Unicode if __STDC_ISO_10646__ is defined, which is the case on Linux/glibc. It's too bad that other platforms are lagging behind on this - there's really no good reason to not guarantee this in 2024. Windows at least has the excuse of having wchar_t be 16-bit which they can't change for legacy compat reasons, but that doesn't explain why e.g. FreeBSD isn't there yet.

This article may give you some informed answer:

https://mitchellh.com/writing/grapheme-clusters-in-terminals

I wonder how many people are using the default b key binding in tmux

> I wonder how many people are using the default b key binding in tmux

I do not use C-b as the tmux prefix key because it interferes with my muscle memory for Emacs where C-b invokes backward-char (i.e., move the cursor back by character(s)).

So I use C-j instead as the prefix key. While C-j also happens to be a useful Emacs key-binding, I use it quite rarely in Emacs. As a result, I do not have strong muscle memory for C-j and I can use it as the prefix key in tmux quite comfortably.

Here is my tiny .tmux.conf: https://github.com/susam/dotfiles/blob/main/.tmux.conf

I use back-tick `. For nested, it becomes `` or ````. For twice nested and I'm writing a shell script with ` instead of $( .. ) It's ```````` (I'm an emacs user, I need all the control characters :)

I also use backticks, and in 99.9% of cases it works like a charm. But then one day you paste a large file, and the gates of hell open. Tmux randomly opens windows, kills sessions, and launches nuclear missiles while processing all the backticks in the text.

I think this can be avoided if you enable “bracketed paste” in your terminal.

Yeah, that's true. Tho for large pastes, I generally only do that in a locally running GUI emacs. For remote, I'll assemble the file and then scp.

Even without tmux, this can be an issue - a long time ago I was using the X windows "drag the selection" middle mouse button action and accidentally let go of the button while the cursor was over an emacs text window - I sent my first email to some big listserv I subscribed to consisting of weird fragments from the log file I was trying to paste.a

I dropped the prefix entirely: https://github.com/jabirali/tmux-tilish

I usually use ctrl+a locally but ctrl+b remotely, so they don't clash when nested.

I use emacs so that meant practically every prefix character would annoy me at some point. I ended up using C-\ since that almost never gets used by anything (I was surprised it could even be detected by terminals).

C-\ is one of my favorite Emacs keybindings :). You use it to change input methods, in my case to write e.g. Greek letters and other Unicode symbols in plaintext files using TeX notation.

I sometimes like to program using Unicode variable names when doing physics/math, and this is an easy way to do so built into Emacs.

I use the default ctrl-b for tmux and changed screen to use the same. I like it because on my keyboard, a Kinesis Advantage, the (left) ctrl and b keys are right next to each other which makes them an easy combo.

No emacs user.

I use p in screen and tmux as prefix key. I usually prefer tmux.

Your use of p surprises me if you don't use b for emacs reasons! How do you go up a line!?

Iam pretty sure that was a recommendation in the emacswiki to use ^P instead of ^A as prefix key (that must be 15+ years ago). I think I didnt invest to much energy to think about an alternative. I almost never use ^P in my terminal emulator, but I use ^A all the time.

I usually never do heavy editing in a tmux window. Rarely I use emacs in a terminal window these days. I use tramp to remote connect and edit comfortably in my X session.

true color support is a big deal. I've been waiting for that for years.