Emacs as your terminal multiplexer

slides: [https://talks.skybert.net/r/2022-emacs-terminal-multiplexer/](https://talks.skybert.net/r/2022-emacs-terminal-multiplexer/) emacs conf: [https://gitlab.com/skybert/my-little-friends/-/tree/master/emacs](https://gitlab.com/skybert/my-little-friends/-/tree/master/emacs) top conf: [https://gitlab.com/skybert/my-little-friends/-/blob/master/top/.toprc](https://gitlab.com/skybert/my-little-friends/-/blob/master/top/.toprc) tmux conf: [https://gitlab.com/skybert/my-little-friends/-/blob/master/tmux/.tmux.conf](https://gitlab.com/skybert/my-little-friends/-/blob/master/tmux/.tmux.conf) tmux theme: [https://gitlab.com/skybert/my-little-friends/-/blob/master/tmux/skybert-theme.tmux](https://gitlab.com/skybert/my-little-friends/-/blob/master/tmux/skybert-theme.tmux)

If you are an evil-mode user I recommend just going into evil mode when using vterm so you can navigate easier.

Timely, I'm just beginning to try and learn screen and/or tmux and wondered was there a need with Emacs.

This was really interesting, so thank you for posting. I enjoyed scrolling through your config files.

Good presentation, Torstein, and workflow. I also use shells in Emacs. But I use a slightly different naming workflow for shell buffers: 1. `F1` for `M-x shell`, and `C-u F1` then spawns a new one instead of going to `*shell*` if it's already open. 2. I can then type `C-c r` to rename it with this snippet: (defun shell-rename-buffer (name) (interactive "sName? ") (if (eq major-mode 'shell-mode) (rename-buffer (format "*shell*<%s>" name)) (error "Not a shell buffer"))) I find that, more often than not, I want to rename an existing shell as often as I want to spawn it with a new name.

Good talk! Though one of the scenarios of using tmux is to run it on a remote host so that all shell sessions are not subject to disruption due to network issues. This is not possible using Emacs TCP server at the moment, possibly due to security concerns[1]. Still I'd like to be able to use C-b freely remotely one day. [1] https://stackoverflow.com/questions/12546722/using-emacs-server-and-emacsclient-on-other-machines-as-other-users

I just open vterm buffers and close them with gay abandon the emacs way

Is it possible to open a multi-vterm buffer in a dedicated directory so I can spawn a multi-vterm buffer with the correct current directory? Now I have a function that uses vterm combined with cd but this messes with the current working directory and magit. Suppose I am working on a project and magit is pointing to the current directory. If I call the shell-in-notes-directory function and go back to magit it points to the ~/org directory instead of the project directory. (defun shell-in-notes-directory () "Shell in the notes directory." (interactive) (cd org-directory) (vterm) )

One of the features of tmux that I use often, but isn't possible (afaik) in Emacs is synchronizing keyboard input on multiple windows.

Terminals is the one area where I always just find it easier to keep a separate terminal window open and alt-tab to it. Sorry Emacs :(.

That question is only about connecting a *local* `emacsclient` to a *remote* Emacs server^1. But that's not what you do. You just do this: $ ssh <hostname> $ emacsclient -nw \**continue using previous shell session running inside Emacs on <hostname>*\* I've never had a need for screen/tmux because of this. ---- ^1 Some people want that so they can have a local GUI `emacsclient` frame, but if you're looking to replace screen/tmux then avoiding terminals wasn't the goal :)

Here I am switching to TMUX for funsies this week.

I end up using kitty for stuff like inline images. I imagine there would be a way to get vterm to support that stuff but honestly it's a bit beyond my pay grade.

Fyi vterm-copy mode (C-c C-t in vterm) lets you move about in the vterm buffer as if it were a normal buffer (e.g. what you wanted with M-x shell)

And how do you navigate readline? I use vi bindings in bash.

If you're in insert mode you can just hit arrow up/down if that's what you're looking for.

If you wait a week I could write a function to do this for you. I don't even know elisp that well for reference. Also, I am very curious how you use this feature as I can't think of a use case.

I think the consolidation of effort you describe w.r.t. themes is great, Torstein: rather than making two things - emacs and tmux - look alike, try to bring the shell experience into emacs. I get why you use vterm for when you need a "terminal" that has all the term-like directives something like htop or vim might want. I was puzzled thoughby your choice of M-x shell over eshell. Have you tried eshell? It seems to hew closer to your theory of consolidation.

Did you read this part? https://github.com/akermu/emacs-libvterm#shell-side-configuration I know it's not exactly what you are asking for but if it is not enabled it's a step in the right direction After rereading maybe all you need is the multi-vterm-project function

Makes sense to me.

Thanks, I'll check it out. Edit: `C-c C-t` is what I've been missing. It makes `vterm` rock even more. Thank you so much, u/FluentFelicity.

This is exactly what I do all the time. It works like a charm. If you replace SSH onto the the host running emacsclient with xpra or mosh, you then have a solution that survives interrupted connections from your PC to to the emacsclient box. It's great for surviving VPN session expiration or moving from the office to home.

Nearly the same setup than Torstein for me. Except that I sometimes run `tmux` inside `emacs`. Why? For session persistence. Two use cases: 1. Remote shell. Running `tmux` inside `vterm` inside `emacs` allows you to benefit from the Emacs-way, while keeping the session running in the remote in case of closing. 2. Crash or accidental closing. Crashes are extremely rare on my side, but when running long commands, keeping them inside a `tmux` session is really helpful. But indeed, all my terminal management is done with `multi-vterm` and `emacs`'s `shell`!

Try https://sr.ht/~niklaseklund/detached.el/

That'd be terrible. I need vi binds to edit my commands in a sane manner.

I find it now other terminals painful to use .. moving around and copying and pasting is just to convenient

Using Emacs to its full capabilities saves a lot of time on alt-tabbing and switching contexts.

Thank you for the suggestions. Unfortunately multi-vterm-project does not solve my problem.

Agreed. evil-collection solves this problem. I use evil-mode throughout and vterm and vi-bindings in my shell. It gives me the best of both worlds - I can still edit the line in readline with vi-mode *and* if I'm in 'normal' mode in a vterm buffer then I can navigate in both dimensions to yank, etc. https://github.com/emacs-evil/evil-collection/blob/master/modes/vterm/evil-collection-vterm.el

You run `tmux` *inside* `emacs`? Wow, that took a bit to settle in :-)

Thanks. Those are great tips, I'll check them out. >I find that, more often than not, I want to rename an existing shell as often as I want to spawn it with a new name. Interesting. For me it's about 50%. I have 4-5 shells I always want and appreciate standard names for these, and then there's the tabs I open where I don't know what I'll be doing with it before I'm deep into something and *then* I re-name it.

Yes, *inside*. :P I benefit from window and buffer management, copy-paste etc. of `emacs`, but the shell session is detached from `emacs` itself since it is run by `tmux`. Note that I do this from time to time when needed -- not for every shell session. By the way, really great video! Sorry to forgot pointing this. Keep the good work.

Thanks!

>By the way, really great video! Sorry to forgot pointing this. Keep the good work. Thanks, u/Drack37, appreciate it.

Thanks for your feedback. >I was puzzled thoughby your choice of M-x shell over eshell. Have you tried eshell? It seems to hew closer to your theory of consolidation. Yes, I've tried `eshell`, but it has never clicked with me. I know that many people love it, but the example I see of lisp and emacs integration hasn't won me over. Perhaps I just haven't "gotten" it. What am I missing out on? I see that I can type `elisp` in it, but I don't have a need for that. When I'm in bash or zsh, that's what I want to write. And if I type `man ls`, I get a `man` buffer with that page. That's nice, but again not something I'd use (I just do `M-x man RET ls`). I keep thinking to myself there's something brilliant I've missed wrt `eshell`, but I have yet to discover it.

[deleted]

They didn't use the familiar `C-c C-j` and `C-c C-k` for switching to their line-mode/char-mode equivalents?

I do `M-x ssh` and have tramp set up to translate that session's pwd... Then it's just `find-file` and I'm editing locally. Mosh would be a really nice tweak to this.

u can also start the emacsclient immediately with the ssh command, just have to use some options, like -t or -p and/or -p? can't remember exactly now, but I used it a lot in the past. u might also want to forward you ssh-agent with -A, but not sure how would the corresponding SSH_AGENT_SOCK env var be picked up by the already running emacs server. but that was tricky to solve for screen and tmux too. so u can have a single command, like ssh -At <hostname> emacsclient -nw

I believe you will see the bottleneck when you try to integrate strictly shell features like the history with Emacs. I forego of the traditional shell history (most recent first) with a directory based system such that when I query the shell history, the commands that were in the _current directory_ is shown first: I've found this behaviour to be far more useful. However, to get this working in M-x shell, I felt that I did a lot of dirty work and that it would have been better in eshell since it is Emacs in the back. [ No idea if that's the case though since I don't use eshell. ]

How do you do without job control in eshell? Job control is one of the features that I don't use often but when I do need it, it is one of the most satisfying things. I think I would be annoyed endlessly if my shell did not have job control.

>I think the present wisdom is to create a new eshell buffer, allowing the "backgrounded" one to run in its buried buffer. From a terminal point of view this is at first bizarre, but stepping back, maybe it's intriguing? I mean, what is the goal of spawning/backgrounding/detaching in terminal interfaces with shells, after all?

When I stop a job (i.e., C-z), I often follow it up with a command that needs to be run in the same directory. I could open a new buffer but then I need to cd into that directory which is a bit more involved. The other pain point with having multiple buffers is that you no longer have an easy way to check on the progress of the jobs; it is a simply matter of `jobs` when you have proper job control. Also sometimes C-z is also used to mean "stop this job right now since I found something else but I might come back to it if this was right after all." I do this when I download something for example.

I maintain a little over 400 servers. Most of the time we maintain them with Ansible scripts, but there are various ad-hoc things I do day-to-day to a random subset of these servers that are so much quicker to do this way. These tasks are often one-time things. Writing some sort of script to do it, though possible, would take more time and be of no benefit to anyone.

As a suggestion that won't require any chance, have you tried using Ansible in a more ad-hoc way. Something like `ansible all -i '/path/to/inventory' -l 'hostgroup1,ip7' -m shell -a "do sruff"`

I haven't. That's a good idea that may replace some of my need for window synchronization. However, some things still don't quite fit into that workflow. For example, I'm often scanning log files on multiple systems and like to scroll them all simultaneously, or sometimes I'm running an ncurses interface on multiple servers at once.

Does mosh handle 24-bit colour already? That was my main gripe.

> never crash Happy to hear it.