Is TMUX necessary when using emacs?

I've been using emacs for a while now, but I never really used TMUX. I've been wanting recently to do some remote development on an OpenBSD server, and TMUX was suggested to me. Is there any point in using TMUX for remote development when you could just use Emacs, Tramp, and Vterm? What about in local development?

if you never really used xyz, you don't need xyz. simple as that. everybody has his own workflow.

Not really, and for what TRAMP + vterm doesn't cover such as unexpected disconnects, there's [dtach](https://github.com/crigler/dtach) + [detached.el](https://git.sr.ht/%7Eniklaseklund/detached.el).

Nope. Different people have different workflows. Some want to use emacs buffers as a way to have multiple terminals, and others want to have a single terminal buffer with a terminal multiplexer. I fall into the latter camp (vterm + tmux = ♥), but neither is strictly better or worse; there's no accounting for taste.

`tmux` isn't really a "remote development" tool, it's a terminal multiplexer. I use it to run shell processes, but it's been part of my workflow long before I started using emacs and haven't fell in love with emacs for that part of my workflow. It's nice to be able to drop a session and reconnect to it from any terminal, it's nice to configure it for a project with `tmuxinator` or similar, and I find the tabs, panes, and scrollback features to be occasionally useful. Before I used emacs, I was running vim inside tmux, but I don't run emacs in the terminal. Since I'm comfortable with my emacs config, and I know how to use tramp, personally I would prefer that for editing on the remote system. But if I have to run processes as part of my development (servers, databases, compilers, etc.), I would probably additionally use a terminal and ssh/tmux to control all of that, even if I was still editing via tramp. Of course, you'll have to find what works for you, but tmux is pretty cool and has a lot of users, I definitely recommend trying it.

Not for me: I have server-start in my init.el and then just use the emacs client to connect and achieves the same thing as tmux. Only problem is I need to be logged into i3, versus tmux that runs as a service.

It is not. But I really like to have emacs and some shells running in tmux on all my computers, so I can login from anywhere and connect to a session and everything is up and running. I used screen for msny years to do the same, but switched to tmux some years ago.

I use emacs within tmux on the remote host so that I can resume working on all the tabs I've opened last time. Maybe there's a way to quickly restore all previously opened tabs in a new emacsclient instance? Anyway being able to manage other long running processes in tmux alongside emacs is also nice.

You don't need tmux to be productive in a remote terminal emacs session. However, tmux is excellent and certainly worth checking out on its own. If you just want a persistent instance of emacs to remain open remotely, consider starting the emacs server and connecting to it with an instance of emacsclient on the remote host. I use tmux locally or remotely depending on my use case. I also use terminal emacsclient on a remote server for most of my day-to-day work. So when I'm working in a remote emacs session it makes sense for me to do that from within tmux, but ymmv. Be aware that the default tmux prefix key will cause issues while in emacs. Try tmux out on its own and decide if using a terminal multiplexer makes life better for you. If it does, then you can always change tmux's prefix key in your config to something that does not interfere with emacs key chords. Good luck and let us know what you try out!

I use tmux with vterm and the reason is simple: it keeps my shell processes independent of emacs. Emacs is much more likely to become unresponsive than zsh or tmux. If I have a problem with emacs, I can just open a different terminal emulator, `kill -9` emacs, and restart it (or maybe I just want to restart emacs for some other reason). Then when vterm reattaches to tmux, all my shell sessions are still there.

Tmux can give you "frame" handling with terminal emacs, but it isn't necessary. Depending on your workflow, it can be useful though

Tmux is wonderful for managing shells/terminals without a graphical environment. For example, ssh'ing into a remote machine and using tmux to keep the session going even if you lose connection or need to use the terminal for something else. But the workflow isn't really the best with emacs. For one, emacs does a lot of the same things: the modeline, window splits, key chords. Also, as you mentioned, TRAMP manages connections in a very different way that may be more useful to you than simply opening a terminal editor. Add to that eshell's ability to cd into remote directories with tramp. So basically, just do what works and only use something if it's useful or fun.

And getting to know new things and tools increases your toolbox. If you limit yourself to “xyz” you are left stagnant.

Apparently this is the emacs way: https://reddit.com/r/emacs/comments/wsmdi4/_/ikz4acs/?context=1

You don't _need_ `tmux` for anything. However one day you'll want to run some long running task and the ssh connection will die right in the middle and you'll be annoyed. That's when you'll look up and find `dtach`, use that for a while, then find out about `screen` and then move on to `tmux`. At least that's what happened to me. So you can just skip all that and go right to `tmux`. :-) Honestly if you're _just_ using emacs on the remote machine it's not going to add much (_especially_ if you are using `emacs --daemon`). I just love it as a way to keep all my work on the remote machine together and persistent.

I use tmux on my local machines because I monitor a couple of small clusters and I like the split the screen into bits so I can see top on all the machines in a couple of screens. On remote machines it can be useful to leave a session running which you can reconnect to later. I do this and leave a tail running on a log file. Emacs and tramp gives you similar funrtions, I guess,so maybe try both and see which works best for your requirements. Using Emacs and tramp with bookmarking, for instance, is a great way of editing files on a remote machine, but a lot of the time I have to do stuff as root (I'm a sys admin), so ssh the machine as local user, become root and attach to tmux session works for my use case. Good luck though. Both are great, and Foss, so experimenting is the be encouraged 😁

Unfortunately some of our tools at work doesn't work well with tramp. So being able to save and restore sessions with all open tabs and buffers in an emacsclient would be great.

Lots of folks run their terminal emulator inside emacs. I find it's never quite as good as the real thing, so I run emacs plus tmux in my terminal app on the side. I wrote a plugin that syncs tmux with the current projectile project... I should release that.

Not really! Tmux is a terminal multiplexer. Whenever I have to work on a remote machine, I ssh into the machine and start emacs as a daemon. Then I attach to it via emacs client, and then spawn multiple vterms within it.

I find `tmux` more resilient if you're dealing with a bunch of processes. I don't use it anymore because I don't really need it, but when I had a more intense shell workflow it was pretty great. I don't really use terminals inside emacs, it's never good enough for me. But to each their own.

Why not just run emacs --daemon on the remote node like I do? I leave and come back all the time, wland keep the same instance running for weeks at a time.

I run emacs --daemon on the remote node and no longer need tmux. I keep it running for weeks

Why not just emacs --daemon? I have all my shells and code and everything inside an emacs daemon I leave running for weeks.

That sounds like it could work too and maybe be better. I have tried to run shellls in emacs in the past but ran into issues. Don't remember what about it that did not work for me (possibly some subjective things). And historically I have not run emacs on every server, but always screen or tmux. Going to try it again.

You mean something like [desktop.el](https://www.gnu.org/software/emacs/manual/html_node/emacs/Saving-Emacs-Sessions.html)?

desktop.el works for new emacs session, but not for emacs server + emacsclient as emacs is still running so the desktop session file is still empty when launching another emacsclient. Or maybe I'm not using it correctly for emacsclient?

You can launch emacs & start a server for it when using the `--daemon` option (e.g.: `emacs --daemon --eval '(server-start)'`). Either `eval` staring the server mode or put it in your init. Then you can connect to that at any point using `emacsclient -c`. You can then just close that frame using `C-x #`/`server-edit` or simply by closing the frame itself by any other mean you feel like. That will leave the Emacs session active, but saving and restoring that session would depend on `desktop.el` functions. edit: You also need to either set the minor mode necessary for automatic desktop session saving or to manually call the saving functions. Similarly for restoring a session. edit2: Personally while I *do* run `server-start` in my init, I still start Emacs in GUI mode and have it manage the instantiated frames via the `desktop.el` functions.

But I don't want to start a new frame but to restore all my previously opened tabs and buffers, like when you reattach tmux everything is still there :)

If I understand correctly, that's generally handled via whole Emacs sessions and desktop.el. If you do use external tools you don't want to close/kill when killing an Emacs session because it leads to unpleasant glitches and annoyances with them, that'd be when detached.el would shine as it fixes that issue.

Well, what I want to achieve is when using emacs daemon after I close emacsclient and open a new one I can restore the tabs and their associated sessions. I know that the buffers are still open as the server is still running, and I can recreate the tabs one by one, but I don't know if there's an easier way to restore those that were previously there.

As far as I know there is nothing to facilitate that use of emacsclient (which you could conceptualize as a subsession of an existing Emacs session to relate to how desktop.el might see it) at the moment. The closest that I'm aware of is what I described above.

Indeed. Thanks for the suggestions anyway! Maybe some ideas for someone to implement in future :)

Try vterm. It is pretty much the defacto around these parts now because, yeah, eshell and ansi-shell have serious issues.

I will check it out. Thanks!

I still use GNU screen. Am I alone in this?

[deleted]

Do you run emacs in the terminal then? Or am I missing something that lets you run a daemon remotely and connect from your local desktop?

Yes I emacs in a terminal on remote machine. I also often use tramp.

\>You can launch emacs & start a server for it when using the --daemon option (e.g.: emacs --daemon --eval '(server-start)'). Either eval staring the server mode or put it in your init ​ Do you need to do server-start when you're launching emacs with --daemon? I've never needed to do server-start when launching with --daemon, so maybe I'm misunderstanding what it does.

When you run emacs --daemon, and then leave, the daemon still runs. I regularly leave and comeback (re-attaching with "emacsclient -c") and all my buffers are still there. ​ What isn't preserved, however, is the frame layout. All the buffers are opened, but any split frames or anything like that are gone. To do that, there's desktop.el, which will save your window layout. ​ You can automate it with (desktop-save-mode 1) in your init.el.

Apparently no, you don't. I assumed it simply backgrounded the process, but according to the manpage it *also* starts the server. My previous example was partly redundant.

Well, as I mentioned in the other post, desktop.el only works for new emacs instances, but not a long running emacs daemon. If you try (desktop-read) in a new emacsclient, you get an error saying that the desktop file is locked. I guess there's currently no tools for that kind of reattach support yet.