> Instead of doing one thing well, it does two things poorly.

It really doesn't. I think you just wanted something to say.

> It's not a very good window manager; when you use tmux you can't easily put a graphical window between two terminal screens

I think wanting to do that is your problem. I appreciate you may have your own insane use case, but mixing x/ptty makes no sense. Try just using your WM to switch to it.

> It's also not very good at keeping programs running. It can't survive a reboot, for example. It's possible to do that, and there's stable software that does it.

What are you even talking about? How is it supposed to know what your running and why you want to keep it running? Do you want your operating system suspend? Do you want to use docker pause/unpause? Then do. You can even script this stuff, which a number have done.

If your workflow unique to you then don't blame a tool designed for a different workflow

> > Instead of doing one thing well, it does two things poorly.

> It really doesn't. I think you just wanted something to say.

I'd say it does at least three things: terminal multiplexing, session management and copy/paste.

I switched away from tmux a while ago and now use DVTM for multiplexing and dtach for session management. DVTM delegates copy/paste to an external editor, but I've not used that functionality.

> every command you send to it has to first be announced with a prefix keystroke.

That's not a bug - that's exactly how every container-style program should work. That way, whatever is running inside the container, talking to the container can never get in the way. It's probably the most frustrating thing about web browsers and most window managers.

I went to effort to make my current window manager work that way (after getting used to it in ratpoison and, of course, screen/tmux).

Well I can appreciate the idea, and there's no other solution that can handle all cases of multiple levels of nested applications that all have their own keybindings (like a web app inside of a web browser inside of a window manager). But in practice I find it to be a horrible experience to use. I used a typical hipster OS X + tmux + vim setup for over a year a while back, so I speak from experience.

Graphic software vendors have essentially all agreed to never use the super key (aka windows key aka command) in their default configuration, an artifact of the time when you couldn't rely on computers having a super key, and of Windows reserving the super key for itself. Most modern window managers only use keybindings that involve the super key. Or at least Gnome 3 does, kinda, except for alt-tab and a few other bindings. Anyway, my window manager config only uses keybindings involving the super key.

It's a much more pleasant window management experience.

But yeah, I don't think there's an alternative that tmux could have used (though mouse integration could alieviate a lot of pain). But that's in itself an argument in favor of not using tmux to manage windows.

You can configure prefix-less keybindings for tmux. It might not be a good idea to do globally unless you know that none of your terminal apps will depend on the same key, but having that in per-project (or per-language) configs might be ok.

I find mouse and clipboard support a bit annoying but there's been changes to that in recent versions of tmux and I haven't reviewed what they do yet.

I haven't got to that part quite yet, but I've been considering adding a few global key shortcuts that would route e.g. run/continue/next/step to my debugger window, regardless of which tmux window is active.

> Generally any program that can handle a suspend and resume can handle being persisted across reboots.

This is not the case for very many of my processes. Are you suggesting DMTCP or something? That won't work with most of the stuff I'm running in terminals.

Other people thought that way I believe, hence the existence of dtach and dvtm. The nice argument is that by decoupling the two functionalities, you get two very tiny binaries instead of one quite ~larger tmux.

  poor mouse support

Well, not to be too snarky but you _are_ running screen/tmux in a terminal window.

And I hope I'm not the only person who considers having to move my hand off the keyboard and onto the mouse a UX bug.

  every command you send to it has to first be announced
  with a prefix keystroke

A friend of mine revolutionized my life when he showed me how he'd remapped GNU screen's command key from Control-A to backquote (`). Using screen went from being moderately annoying---especially to a die-hard Emacs user like myself---to being an essential part of every Unix/Linux server install I have done since. To be honest I don't understand why screen and tmux don't default to backquote instead of Control-A/Control-B, but maybe that's just the twenty-plus years of Unix-induced brain damage talking. :)

Probably because backquote is very often used by many people. In particular, people like myself who do a lot of Lisp programming. Outside Lisp, backquote is also used in sh (unless you want to give yourself RSI by using $(...)).

And this is the problem in a nutshell, there really is no single keystroke that everybody can agree is the perfect one to use. You obviously don't use backquote much, so for you, thats the perfect one. For me, Control-W is pretty good, unless of course I have to run Emacs at which time it becomes a terrible choice.

  You obviously don't use backquote much

I use backquote pretty heavily, but I find typing "``" to get a literal backquote in the terminal to be much easier (and less stressful on my hands on modern PC keyboards) than "C-a a" to get a literal Control-A. YMMV.

shellcheck has some interesting things to say about `` vs $()

Yes, I noticed. I also noticed that it doesn't justify that assessment by anything more than referring to ` as "legacy".

I'm not sure how much trust I would put into shellcheck. Especially since it doesn't flag the common error of "export FOO=bar" (instead of "FOO=bar ; export FOO").