Emacs as terminal multiplexer: Speed

Just a wee bit of fun, comparing the speed of using Emacs as a terminal multiplexer to that of `tmux`: * tailing lots of text * switching between terminals * opening new terminals Slides & conf: * 🎞️ Slides: [https://talks.skybert.net/r/2022-emacs-terminal-multiplexer2/](https://talks.skybert.net/r/2022-emacs-terminal-multiplexer2/) * 📑 Emacs conf: [https://gitlab.com/skybert/my-little-friends/-/tree/master/emacs](https://gitlab.com/skybert/my-little-friends/-/tree/master/emacs) * 📑 tmux conf: [https://gitlab.com/skybert/my-little-friends/-/tree/master/tmux](https://gitlab.com/skybert/my-little-friends/-/tree/master/tmux)

Thank you for the videos on the Emacs as a terminal multiplexer topic. I am looking forward to migrating from Tmux to Emacs (vterm) but one of the killer features of Tmux for me is that I can close the terminal window and I can re-attach to the shell later. Meaning, it can survive X crashes. This would be even more useful in Emacs because it freezes on me from time to time (some mu4e issue). I think `detached.el` could be it but I haven't figured out how to use it. Have you experimented with anything like this?

Would running Emacs as a server with emacsclient work?

How about using screen?

Only if you run the Lucid build. Gtk being Gtk backstabs Emacs when X dies.

> Meaning, it can survive X crashes. Just curious: how often does X crash on you? I haven't had a crash in probably 10 years. Possibly a consequence of switching from proprietary nVidia drivers to Intel hardware and OSS drivers, or things have just gotten more stable in general > Emacs because it freezes on me from time to time Yes, I do get this too on occasion. For me it's LSP/java/eclipse that locks Emacs up. For that reason, I like to have two Emacs. One that never crashes and one that's more unstable. > Have you experimented with anything like this? No, I just use `emacs --daemon` and detach and attach with `emacsclient`.

What about installing the `emacs-nox` package (or equivalent)?

Why choose? Just use Tmux inside VTerm, and you will get the better of both world.

maybe look at dtach(.el) for this feature: https://www.reddit.com/r/emacs/comments/rgwlfx/dtacheel_a_package_for_detached_shell_commands/

That was my first choice but I couldn't figure out how to use it. I was able to run detached processes, but I don't understand how to create a detachable `vterm` instance.

> I like to have two Emacs. One that never crashes and one that's more unstable. I am going to do the same, thanks :-) > Just curious: how often does X crash on you? I am experiencing this very weird, Qtile issue https://github.com/qtile/qtile/issues/3276 so I need to kill Qtile probably once a week. If it was any other DE/WM, I would have ditched it a long time ago, but Qtile has a special place in my heart :-)

Are you using it? If yes, could you please share your experience? At first, I thought Vterm + Tmux combination is a great idea, but when I tried it, I arrived at the conclusion, that it brings the worst from both worlds. - When using Vterm + Tmux, you (I am using the generic you here) leave the buffer management to Tmux, so you still use `C-b c` for creating a Tmux window, `C-b n`, `C-b p` `C-b l` for window switching, etc. Some time ago I started working on Emacs an Emacs wrapper around it, so I could use helm for buffer manipulation but I got distracted by other issues - Scrolling is done by Tmux, therefore you cannot scroll up and down, and jump around like in any other Emacs window. - Tmux is modal, and I am using Evil keybindings. The complexity skyrockets here. For example, to scroll, you need to switch to insert mode in Evil, so you can press `C-b PgUp` to switch into scroll mode in Tmux. Afterward, you need to exit both to get into normal. The fun happens when you have the muscle memory to press ESC after everything, and end up in normal mode in Evil but the Tmux is still in scroll mode. Then it requires some thinking to get back to untangle it. - You still need a solid Tmux config for it to look good, support colors, etc I think it would be killer if we could decouple Tmux rendering from its backend. I don't know if it is complete nonsense or not but I imagine it as Tmux managing the sessions, windows inside them, and their contents. Then instead of using the standard Tmux interface, we would connect to it using an elisp library and use Emacs to interact with it. A big chunk of this work is done in https://github.com/emacsorphanage/emamux but it AFAIK doesn't help with the scrolling issue and the modal complexity issue. Edit: I said it incorrectly. Tmux has server-client architecture and there are ways to interact with it from the outside (so listing panes, creating them, that's easy stuff). What I meant specifically is interacting with the actual terminal that is represented by a pane, from the outside of Tmux. That I have never seen before and I don't know if it is nonsense or not.

Do you mean opening vterm, running `screen` command, and working inside? I don't know much about screen, but I have been using Tmux for years and tried to use it like this. Please check out this comment https://www.reddit.com/r/emacs/comments/wkdhdf/comment/ik1godm/?utm_source=share&utm_medium=web2x&context=3 I think when using screen, I would run into the same issues. What do you think?

That's a good point. I'm not sure how to, or whether, vterm itself could be detached like this.

> If it was any other DE/WM, I would have ditched it a long time ago, but Qtile has a special place in my heart :-) I hear you. For me, it used to be Fluxbox. Used it from 2002 to 2018 when I finally "gave in" and switch to a tiling window manager (in my case, `i3`)

I've been wondering if one could get the best of both worlds using `tmux` CLI commands with a minimal chrome & config with `vterm` together... Have some persistence outside the emacs world, a session that's exposed for piping, scripting, etc... And my iPad term of choice embeds `tmux` session control too so I can pick-up and run when away from "home".

Sorry for the late response. Here is my experience briefly. Most of the time, I work with Vterm only, not Tmux. Tmux is only for very long and important process with visual feedback, or for remote sessions. About buffer management, usually I only have a few Tmux panes and only one window. So most of the buffer management is still done with Emacs. Remember, Tmux is only for long live processes or shell, so there are not many. About scrolling, Tmux has a copy-mode just like Vterm. Use `C-b scroll-up` (or `scroll-down` keyboard button) to enter it, you will be able to scroll up and down, and copy text. About evil keybindings, I don't have any problems since I don't use it. Finally, I already had the "solid" Tmux configuration since I used it with Vim before to fall into the Emacs world.

Hi there, detached.el author here. As you say detached processes are supported with vterm integration but detaching a whole vterm instance is not. I guess one way around it could be to launch your shell, e.g. bash with detached inside a vterm. Then the whole shell session would be detachable. Is that what you are after?

The approach I suggested doesn't seem to work at the moment. I think it has potential to work in the future. I will look into that possibility :)