[ori_b]

The thing is that without hijacking it and passing it through, you can't have nice things like handling resizes, supporting attaching with multiple terminal emulators, or reconnecting to applications that make heavy use of terminal escape codes, because all of those set up persistent state in the terminal emulator.

As a result, any tmux-like layer needs to emulate a console in order to get a view into the state, and then re-render that emulated console on attach to restore state to the terminal emulator that you're connected from.

From the readme, this tool does that, kinda. I'm actually confused about why they'd go to the effort of implementing a VT100 emulator, write the code to redraw the screen from it, and yet not bother with doing the work that would let multiple terminal emulators attach.

This feels like it sits in a weird place between simple, crude tools like dtach, and tools like tmux; shpool has done most of the work to implement tmux-style behavior, and then decides to cut weird corners.

[ethanpailes]

You definitely don't need the in-memory terminal emulator to handle resizes or allow attaching with multiple local terminal emulators, since dtach does both and does not have an in-memory terminal emulator.

> I'm actually confused about why they'd go to the effort of implementing a VT100 emulator, write the code to redraw the screen from it

Well, we kinda cheated here. shpool_vt100 is just the already existing vt100 crate with a single critical bug fixed, so it actually wasn't much work :). Turns out having a nice package manager for a systems language comes with some benefits.

I'm actually open to adding a feature to allow multiple simultaneous connections to a single session. I never really had a usecase for it personally so I haven't prioritized it, but it is something that similar tools support and people keep bringing up. Since this isn't the first time I've heard people talking about it, I just made https://github.com/shell-pool/shpool/issues/40 to track work adding the ability to attach multiple clients to the same session.

> This feels like it sits in a weird place between simple, crude tools like dtach, and tools like tmux; shpool has done most of the work to implement tmux-style behavior, and then decides to cut weird corners.

I'm not aware of any tool that does internal rendering and subsetting handling scrollback and copy-paste in a way that I personally find usable, so these decisions were very much intentional.

I think tmux is a great tool for a lot of people, and I tried to get into it for years, but I could just never get over the weird scrollback and copy-paste issues or the fact that it meant that I couldn't use my normal `i3`/`sway` bindings to switch between terminals inside a tmux session. If tmux works for someone, I think that's great and they should keep using it. shpool is meant for people like me who aren't very good with computers :).

[bee_rider]

I’m not sure what the popular use case is for multiple connections to one multiplexer. But, two (niche seeming) ones could be: if you have a desktop, you want to be able to SSH to it and use it locally at the same time. Or, if you have two people ssh-ing to one system, and letting them share a terminal might be nice (although in that case it would really be nice to give them independent cursors, which starts to become an involved project).

[Geezus_42]

I usually have a drop down terminal that I use the most, then a full screen window on some other space. I can switch between them quickly and connect to any of my sessions from either.

[Jtsummers]

Or one person ssh'ing to the same remote from two or more devices. If I don't feel like sitting in the office (desktop) and grab the laptop and go to the sitting room or back deck I can continue my session without issue, and then transition back later. I don't want to have to disconnect/detach a session when I do this, I want it to be seamless so both connections (actually three typically, an iPad as well) are running continuously.

[CoolCold]

we do use multiconnections when doing interviews - candidate solving test case on VM, interviewers are observing. Idea was not to confuse candidates by requiring screensharing during the interview, just see the particular ssh session.

[mkhnews]

Hi. Nice kit. > I couldn't use my normal `i3`/`sway` bindings to switch between terminals inside a tmux session Just curious, what are your normal 'i3'/'sway' bindings that you cannot get to work with tmux ? And what actual terminal program do you use ? Perhaps tmux wants more config than most people care to bother with, but scrollback and copy-paste can be configured just as you like.

[ethanpailes]

If you’re using a tiling window manager your window switch keybindings necessarily conflict between the manager and tmux, since if you configure the same one and then press it while focused on a tmux window, the tiling window manager will override tmux and claim the event.

Scrollback and copy paste cannot always be configured as you want. I’ve shared some specifics elsewhere in this thread.

[mkhnews]

Hi. ok, I get that. Maybe something like A-left to move to next i3 window and A-S-left to move to next tmux window within an i3 window ? Perhaps a tiling window manager with multiple windows combined with tmux dividing some of those windows further into sub-windows isn't an ideal flow.

[qi437103]

It's not i3/tmux, but a similar problem exists for vim/tmux, where the vim window management keys will conflict with tmux's.

And there's https://github.com/numToStr/Navigator.nvim that unifies the keys by letting the outside layer (tmux) always ask the inside layer (vim) before any movements.

Although that is indeed a lot more setup. But works pretty well.