Duplicate terminal feature, make session management more vim-like

[alexryndin]

At the moment, tmux lacks the GNU screen feature to choose the same session (terminal) in different panes.
What I propose is session management rethink to make it more vim-like.
As you may know, in vim different open files are managed as buffers, and buffers are not tied to specific splits (panes in tmux's terminology). You can also have different tabs in vim (windows in tmux's terminology), containing as many splits as you want, and at any time you can choose and show any buffer in any split. Unlike vim, tmux ties up a terminal to a pane, so you can't duplicate an open terminal session, and if you want to see the same session in a different window your only way is to move a whole pane. And then, if you want to bring the terminal session back in the previous window, you have to move a whole pane again. With a vim-like session management, if you'd want to see a session in a different window, you would:

1. Open that window
2. Make another empty pane (what tmux can't do at all at the moment)
3. Open a list of open sessions in that pane and choose a session.
   And then you would have the same session in two different windows in different panes.

A little investigation shows that I'm not the only user who wants this feature -- https://unix.stackexchange.com/a/105457.

[nicm]

Detaching the pty part of panes from the displayed part has been a todo list item for a long time, but it is substantial effort. Are you proposing to do the work?

That is the basic requirement to be able to display the same pane in multiple places, although there are of course a lot of further questions, for example how would sizing work, how panes would be targeted, and what the interface would look like. I am not particularly convinced about the idea of allowing panes to be wholly independent, my feeling is that they should always be present in at least one window and session.

Note that the model for tmux should be emacs not vim, although in this respect they behave similarly (buffers are not bound to where they are displayed).

You should note however that I do not want a model like GNU screen where the pane layout is lost when detached. It is very important that when somone reattaches to a tmux session everything is exactly as they left it, only adapted to the new terminal size and capabilities.

[nicm]

The big changes we need are, off the top of my head:

• Split struct window_pane into two: one struct containing the pty stuff (fd, parser stuff, pty size, etc) and one struct (I suggest "panelink") similar to struct windowlink which connects a window to the pane it is displaying. This would be relatively straightforward but time consuming.

• Ptys displayed in different sizes of panes must be handled. At the moment windows may be oversize and are cropped and panned, but panes may not be. As a first step ptys could be limited to the smallest pane in which they are displayed, but that would only be a stopgap, eventually they would need pan which would be complicated and considerable effort.

• Commands would be needed to link a pane into a window, this would mostly be changes to existing commands to use an existing pane (such as split-window/join-pane/swap-pane). Not terribly difficult.

• Targets and cmd-find.c would need to be extended to handle the situation when a pane ID is given but the pane appears in multiple places but the window or session is needed. This would be similar to how the "best window" is chosen at the moment. Again probably not terribly difficult.

There will also probably be a large number of smaller changes to places where there is an assumption that a pane exists in one window.

[alexryndin]

@nicm GNU screen's ability to loose layout on detach doesn't look good for me too :). I very like how tmux saves layout.
As for interface, I like how screen handles this. Consider resizing:

In the screenshot above you can see GNU screen with three panes, all of them having the same terminal opened. first and second panes have the same size, so vim doesn't get shrunk there, whereas third pane have higher height, so vim gets shrunk.
To choose a terminal I suggest interface similar to what :choose-tree, but containing a list of all terminals open, and instead of bringing you to the pane selected, this would bring terminal to the pane you stay at :)

[nicm]

Yes, the problem is not doing what to do, it is implementing it.

choose-tree can also do it but it is not enough alone, there would also need to be changes to the other pane commands.

If you are not planning to work on this, I will close this issue since it is already on the todo list, however I will link this issue from the todo entry.

[alexryndin]

@nicm glad to know that it is already on the todo list :)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

[topcat001]

@alexryndin we now have the ability to display the history of one pane in another, and it can be refreshed at will. Does it address at least some of the use cases for duplicating the pane? It seems to me that it does address the stackoverflow question you posted. I understand that it is not quite what you're looking for. Thanks!

@nicm Reopening it temporarily just to get some feedback on this.

[topcat001]

@nicm do you think it's worth spending time on this? I will be able to work on this soon and it looks like a very interesting project to further my understanding of tmux.

[nicm]

Sure you can work on it if you like but I think it will be complicated so if I was you I would try to get a good idea of what it will look like once it is done and how to break the work up. Splitting pty from pane should not be that difficult (we already support non-pane ptys now like popups), but I don't really know how all the UI and stuff will look, and how we will deal with panes shown in two places at different sizes.

Other big things that are on the todo list is a better way to have clients attached to the same session with an independent current window. Or improving how layouts work (for example so they can be sticky). Or hooks need a lot of work (although hooks are pretty boring).

[topcat001]

Thanks for the feedback. This gives me some things to think about. I'll close this issue for now and pursue these in a new thread.