Hi could be considered to add an option to hide/unhide a pane or window?

[Ergus]

This is actually a feature request,

Could we consider to add an option to hide/unhide a pane like the resize-pane -Z but inverse? The idea is to be hable to open a temporal panel and keep the history information. (Useful for example when working with an editor and want to compile or debug the current code temporarily, and go back and forth)

• I tried something like resize-pane -t 2:0.1 -y 0 but it keeps one line of the target pane, so it not really hiden.

• Then I have a bash script like this:

_split() {
	local wid=$(tmux display-message -p '#{window_id}')
	local toggledid="$(tmux show-options -wv @toggleid)"
	local stack=":1000"

	#  var is set         session exists
	if [[ ! -z "${toggledid}" ]] && $(tmux has-session -t $toggledid); then

		local toggledwid=$(tmux display-message -p -t ${toggledid} '#{window_id}')

		if [[ "${toggledwid}" == "${wid}" ]]; then
			# Panel exists and is visible.. so hide it
			if $(tmux has-session -t "${stack}"); then
				# The window stack already exists, so append
				tmux join-pane -dv -s "${toggledid}" -t "${stack}.bottom"
			else
				# The window 100 does not exists, so break (to create)
				tmux break-pane -d -n "stack" -s "${toggledid}" -t "${stack}" \;\
					 set -w -t "${stack}" window-status-current-format '#[bg=red,fg=colour15,bold] #W ' \;\
				     set -w -t "${stack}" window-style bg=blue \;\
					 set -w -t "${stack}" window-active-style bg=blue \;\
					 set -w -t "${stack}" pane-border-status top
			fi
		else
			# The pane exists in other window so, get it back
			tmux join-pane -v -l 10 -s "${toggledid}" -t ".bottom"
		fi
	else
		# The pane does not exist, so create one and it gets active
		tmux split-window -v -c '#{pane_current_path}' -l 10 -t ".bottom" \;\
		     set -wF -q @toggleid '#{pane_id}'
	fi
}

That goes around the limitation a bit, but it is very limited and sometimes conflicts with next-window or swap-window.

So far I see several possible solutions here:

1. Allow negative values for windows, meaning that any value below base-index is considered like disabled but still local to this section. This may work but has a side effect of keeping session fully hidden, so maybe requires extra modifications...
2. Really hide the pane somehow
   (looking at the code it may be something like what zoom-window does but calling:

wp1->saved_layout_cell = wp1->layout_cell;
wp1->layout_cell = NULL;

But applied for a single pane.
3. Allow zero sizes in the resize-pane command so the panel will be here but not visible.
4. Implement a sort of toggle pane inherent to every window that can be hidden like the status-bar.

Does it makes sence?
Best,
Ergus

[nicm]

Adding a special kind of hidden window or pane would add a lot of complexity when you could just as well move the pane or window to another session and back to hide it. You can filter the session out of choose mode if you don't want to see it.

[Ergus]

Adding a special kind of hidden window or pane would add a lot of complexity when you could just as well move the pane or window to another session and back to hide it. You can filter the session out of choose mode if you don't want to see it.

The addition of an special kind of window is just one of the alternatives. But moving to another session somehow will make very complex to have some kind of locality and may introduce issues with options like destroy-unattached.

To have an invisible panel in principle it is not very different to zoom/unzoom (set layout with size zero) or assign it a null layout and save the previous one. An invisible window (or at least a window ignored is something as simple as just add a flag to it in order to make it ignored by switch or move commands loops...

For example in emacs, the panels starting with a space in the name are not shown, listed or anything.

Filtering out from choose mode is not an option for me because I never ever use any choose like panel..

Actually this is related the same somehow because the desired behavior it what tree-choose brings: a temporal terminal for single or sparse use.

What you suggest is more or less what my code tries to do, but I don't move it to a different session in order to respect destroy-unattached. So I move the panels to a high number window in the same session and hope.

Is there a reason why I can't set a y 0 to a panel?

Thanks for your reply,
Ergus

[nicm]

I don't find your problems with moving to another session very compelling I'm afraid. Problems with destroy-unattached seem trivial (turn it off when you have hidden windows?), you can use user options to store whatever locality information you need, and if you don't use choose mode, it should still be relatively simple to make whatever bindings you do use skip hidden windows using if-shell -F.

Removing a pane from the layout and flagging it so every loop skips it is adding a special kind of pane. The fact is that tmux's model is that every pty must belong to a pane, every pane to a window and every window to a session. And every pane must be visible - zooming is very much a special case of "only one pane" and even for it we unzoom before doing anything complicated.

Changing fully to a model where things (ptys or panes) can float would be a big and disruptive shift and I can't see that some halfway thing where panes can be kind of hidden but also not would be much better than just using a special session.

I would be OK with some changes if there are small things that would make the behaviour you want easier - maybe we make it so you can target the next window matching a filter, so instead of doing:

selectw -t:+

You could do something like:

selectw -t+#{?#{@hidden},0,1}

To skip windows where the @hidden option was true.

Or feel free to make other suggestions, but I don't think we are just going to have a way to say "hide this pane/window from everything", at least not anytime soon.

[Ergus]

You could do something like:

selectw -t+#{?#{@hidden},0,1}

That may be acceptable too to add a -F to some other commands. It may be confusing to know if @hidden refers to current or target window, but with a right documentation could be enough.

[nicm]

You can already do this by wrapping the command in run -C but I have added to the todo list to make it so that -t can expand formats itself.

I have been thinking about this a bit more and I am perhaps a little more convinced about its usefulness.

I still think that making a real "hidden pane" or "hidden window" would end up being no better than just moving the pane or window to a temporary session. A session is just a list of windows and panes, so adding our own "hidden panes" list is redundant.

But I think we could extend the zoom mechanism to allow panes to be hidden. This is close to one of your suggestions. What I think we could do is:

• Currently, when we zoom, we save the existing layout and create a new one just with the pane we are zooming to.

• We could extend this so that we do the same thing, except we create a new layout without the pane we want to hide.

• If the user wants to hide a second pane, the saved layout would already exist, so there would be no need to save it again and we could just remove the pane from existing layout.

• Zooming would be the same as hiding all except one pane.

• Any action which changed the layout, number of panes, etc would cause a complete unzoom back to the saved layout, the same as it does now.

This would be relatively simple to do but would - at least initially - not allow unhiding individual panes or mixing hide and zoom.

Would this work for you?

[Ergus]

Hi @nicm :

So far if -t expands formats I think it may be good enough for me... My function is already implemented with some tricks here and there and it seems this feature is not very demanded any way.

The rest of your proposal will end up with some complex corner cases that I agree maybe don't worth it. I mean. The first use of the hidden panel may be to have a sort of toggle pane to hide-show in the current window. If the split shows the pane back it may end up being more unconformable than useful IMHO.

The issue with temporary session is that when I set the destroy-unattached on I need a hook to set it off for that specific section and assert that when I close the windos X:Y I also close the pane on the temporal session and so on. It is disable, but very cumbersome. With the extra effort that when xterm closes externally then not all the hooks are executed so many panels stay alive in the session.

[nkh]

Hi, I wrote https://github.com/nkh/tmuxake to do something similar.

a quick and dirty and slooow screencast
https://asciinema.org/a/H1hCG8Kb4T10pdI20kgMmsbOi

[nicm]

I have added this (-t expands formats) to todo list and as you say the rest is probably better left for the moment.

[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.